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 les traces d'exception de Strack et je voulais les traces de pile pour inclure les noms de fichiers et les numéros de ligne lorsqu'ils sont déployés dans la production. Je me suis dit comment déployer les symboles de débogage w / l'ensemble, mais dans le processus de recherche sur la question que je courais accross blog de John Robbins lien dans la réponse de Michael Maddox genre de sautait sur moi:

  

A seulement .NET PDB contient deux morceaux de   informations, les noms de fichiers source et   leurs lignes et la variable locale   des noms. Toutes les autres informations sont   déjà dans les métadonnées .NET donc il   est pas nécessaire de reproduire le même   informations dans un fichier PDB.

Pour moi, ce Réitère ce que les autres ont dit à propos de réflecteur, avec l'implication étant que la vraie question est l'accès aux assemblées. Une fois que cela a été déterminé, la seule décision à prendre en ce qui concerne PDB est de savoir si oui ou non vous souciez d'exposer les noms de fichiers, les numéros de ligne, et les noms de variables locales (en supposant que vous ne montrant pas trace pile à l'utilisateur final pour commencer). Ou ai-je trop ce trop simplifié?

Answer 1

Voici une autre question à examiner:

Est-ce il des problèmes de sécurité en laissant les fichiers de débogage PDB sur les serveurs live?

Et plus d'informations sur les fichiers PDB:

Fichiers PDB: Ce que tout développeur doit savoir

En général, je toujours inclure pdb dans mes déploiements, les gains sont trop énormes pour être ignorés.

Si vous ne l'exposerai pas une trace de la pile à vos utilisateurs (et généralement vous ne devriez pas), il n'y a pas vraiment de risque de sécurité supplémentaire de déploiement PDB.

Quand une trace de la pile visible de l'utilisateur se produit, l'utilisateur peut voir la trace complète de la pile, y compris votre nom de fichier et les numéros de ligne de fichiers. Cela pourrait leur donner une idée de la façon dont votre application est architecturée qui les aiderait potentiellement si le piratage.

Une plus grande menace pour la sécurité est quelque chose comme réflecteur qui, lorsqu'il est utilisé sur votre DLL sera leur permettre de voir votre code source, avec ou sans pdb.

Answer 2

Si vous déployez à un environement de production dans votre propre organisation, il n'y a pas un problème de sécurité.

Si vous vendez votre logiciel à d'autres entités, puis .pdb peut donner à quelqu'un intéressé par l'ingénierie inverse une jambe -. Qui peuvent ou peuvent ne pas être un problème pour vous

Toutefois (pour être clair), vous ne voulez pas que vos traces de pile affichés au client - si oui ou non les .pdbs sont disponibles. Mais si vous vous connectez simplement les traces et la présentation d'une page d'erreur « jolie » au client, ce n'est pas un problème.

Answer 3

En ayant des symboles de débogage, un attaquant peut déterminer les variables globales, des décalages de fonction, etc., d'intérêt.

Alors, il pourrait voir votre système a une fonction comme:

AddAdminUser(string name, string password);

Et connaître son décalage. Si votre programme est compromise, 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 ce bit à retourner pour changer votre application en mode non sécurisé.

Sinon, cela prendrait un peu de temps d'ingénierie inverse pour comprendre. Pas une quantité insurmontable de temps, cependant.

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

Si vous avez une bonne raison d'affaires de déployer des symboles pdb, allez-y. Le déploiement de l'APB ne vous fera pas l'insécurité. Si vous ne disposez pas d'une bonne raison de déployer, vous ne devriez pas le faire car il fera des attaques un peu plus facile.

Vous pouvez également créer des fichiers PDB publics - ces bandes certains éléments d'information, mais vous donner suffisamment de symboles pour générer une trace de la pile et faire le débogage de base. Les détails sont . Microsoft déploie PDB publics de son serveur de symboles pour tous à utiliser.

EDIT: La plupart de ce que je dis applique aux préoccupations autour du déploiement des années PDB pour le code natif - Je pense que beaucoup de ces préoccupations des gens portent vers .NET et, même si les métadonnées d'assemblage véhicule un peu de ce déjà <. / p>

Answer 4

Quelqu'un peut « restaurer » le code source complet de votre application. Si elle est Open Source vous ne devez pas vous inquiéter. Si elle a un certain IP (algorithmes, protection, licences), il est sans doute pas une bonne idée.

Il est vrai que des outils comme réflecteur peuvent reconstruire des parties de votre code, même sans PDB, mais obscurcissements peut aider (bien, juste un peu).