Quel est le risque de déployer des symboles de débogage (fichier pdb) dans un environnement de production ?

Question

J'ai une application qui enregistre des traces de pile d'exception et je voulais que ces traces de pile incluent les noms de fichier et les numéros de ligne lorsqu'elles sont déployées en production. J'ai trouvé comment déployer les symboles de débogage avec l'assemblage, mais au cours de mes recherches, j'ai rencontré les problèmes suivants cette question ce qui implique que ce n'est pas une bonne idée d'inclure des fichiers pdb dans un environnement de production. Un commentaire à la réponse acceptée dit "...les informations de débogage peuvent donner des données sensibles et être un vecteur d'attaque. Cela dépend de la nature de votre application."

Quel type de données sensibles pourrait être exposé ? Comment les symboles de débogage peuvent-ils être utilisés pour compromettre une application ? Je suis curieux de connaître les détails techniques, mais ce que je recherche vraiment, c'est un moyen pratique d'évaluer le risque d'inclure des symboles de débogage pour une application et un environnement de production donnés. Ou, pour le dire autrement : quel est le pire qui puisse arriver ?

EDIT : question de suivi/clarification

D'après les réponses données jusqu'à présent, il semble que cette question puisse être simplifiée pour les applications .NET. Ce passage de la Le blog de John Robbins lié à La réponse de Michael Maddox m'a en quelque sorte sauté aux yeux :

Une PDB .NET ne contient que deux éléments d'information. informations, les noms des fichiers sources et leurs lignes et les noms des variables locales locales. Toutes les autres informations sont déjà dans les métadonnées .NET. Il n'est donc pas nécessaire de dupliquer les mêmes informations dans un fichier PDB.

Pour moi, cela réitère ce que d'autres ont dit à propos de Reflector, avec l'implication que le vrai problème est l'accès aux assemblages. Une fois que cela a été déterminé, la seule décision à prendre en ce qui concerne les PDBs est de savoir si vous vous souciez ou non d'exposer les noms de fichiers, les numéros de lignes et les noms de variables locales (en supposant que vous ne montriez pas les traces de pile aux utilisateurs finaux pour commencer). Ou ai-je trop simplifié les choses ?

Answer 1

Voici une autre question à examiner :

http://stackoverflow.com/questions/933883/are-there-any-security-issues-leaving-the-pdb-debug-files-on-the-live-servers

Et plus d'informations sur les fichiers PDB :

http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/05/11/pdb-files-what-every-developer-must-know.aspx

En général, j'inclus toujours les fichiers pdb dans mes déploiements, les gains sont trop importants pour être ignorés.

Si vous n'exposez jamais une trace de pile à vos utilisateurs (et vous ne devriez généralement pas le faire), il n'y a pas vraiment de risque de sécurité supplémentaire à déployer des fichiers PDB.

Lorsqu'une trace de pile visible par l'utilisateur se produit, l'utilisateur peut voir la trace de pile complète, y compris le nom du fichier et les numéros de ligne du fichier. Cela peut lui donner une idée de l'architecture de votre application, ce qui pourrait l'aider en cas de piratage.

Une plus grande menace de sécurité est quelque chose comme Réflecteur qui, lorsqu'il est utilisé sur vos DLLs, leur permettra de visualiser votre code source, avec ou sans fichiers pdb.

Answer 2

Si vous déployez un environnement de production dans votre propre organisation, il ne s'agit pas d'un problème de sécurité.

Si vous vendez votre logiciel à d'autres entités, le fichier .pdb peut donner à une personne intéressée par la rétro-ingénierie une longueur d'avance - ce qui peut ou non être un problème pour vous.

Cependant (pour être clair), vous ne voulez pas que vos traces de pile soient affichées au client - que les .pdbs soient disponibles ou non. Mais si vous vous contentez d'enregistrer les traces et de présenter une "jolie" page d'erreur au client, ce n'est pas un problème.

Answer 3

En disposant de symboles de débogage, un attaquant peut déterminer les variables globales, les décalages de fonctions, etc. qui l'intéressent.

Donc il pourrait voir que votre système a une fonction comme :

AddAdminUser(string name, string password);

Et connaître son décalage. Si votre programme est compromis, il pourrait appeler cette fonction pour se donner des privilèges d'administrateur.

Ou quelque chose comme :

typedef enum {Basic, NTLM} AuthenticationMode;
AuthenticationMode g_authenticationMode;

Et sait quel bit retourner pour faire passer votre application en mode non sécurisé.

Sinon, cela prendrait pas mal de temps de rétro-ingénierie pour le découvrir. Pas une quantité insurmontable de temps, cependant.

Mais tout cela implique que votre attaquant est déjà dans une position où il peut compromettre votre programme. Si c'est le cas, vous avez déjà perdu.

Si vous avez une bonne raison commerciale de déployer des symboles pdb, allez-y. Le déploiement de symboles pdb ne vous rendra pas insécure. Si vous n'avez pas de bonne raison de déployer, vous ne devriez pas le faire car cela facilitera légèrement les attaques.

Vous pouvez également créer des fichiers PDB publics. Ceux-ci ne contiennent pas certaines informations, mais vous donnent suffisamment de symboles pour générer une trace de pile et effectuer un débogage de base. Les détails sont ici . Microsoft déploie des PDB publiques sur son serveur de symboles pour que tout le monde puisse les utiliser.

EDIT : La plupart de ce que j'ai dit s'applique aux problèmes de déploiement des PDB pour le code natif - je pense qu'un grand nombre de ces problèmes s'appliquent également à .NET, même si les métadonnées d'assemblage transmettent déjà une grande partie de ces informations.

Answer 4

Quelqu'un peut "restaurer" le code source complet de votre application. S'il s'agit d'un logiciel libre, vous n'avez pas à vous inquiéter. Si elle possède une certaine propriété intellectuelle (algorithmes, protection, licences), ce n'est probablement pas une bonne idée.

Il est vrai que des outils comme Reflector peuvent reconstruire des parties de votre code même sans fichiers PDB, mais les obfuscations peuvent aider (enfin, juste un peu).