Каков риск развертывания отладочных символов (pdb-файла) в производственной среде?

Question

У меня есть приложение, которое регистрирует трассировки цепочки исключений, и я хотел, чтобы эти трассировки стека включали имена файлов и номера строк при развертывании в рабочей среде.Я выяснил, как развернуть символы отладки без сборки, но в процессе изучения проблемы я столкнулся с этот вопрос, что подразумевает, что включать pdb-файлы в производственную среду - не очень хорошая идея.В комментарии к принятому ответу говорится: "... отладочная информация может выдавать конфиденциальные данные и быть вектором атаки.В зависимости от того, что это за приложение. "

Итак, какие конфиденциальные данные могут быть раскрыты?Как отладочные символы могут быть использованы для компрометации приложения?Мне любопытны технические детали, но то, что я действительно ищу, - это практический способ оценить риск включения символов отладки для любого данного приложения и производственной среды.Или, говоря по - другому:что самое худшее, что может случиться?

Редактировать: последующий вопрос/разъяснение

Итак, основываясь на ответах всех, кажется, что этот вопрос можно немного упростить для .NET applications.Этот фрагмент из Блог Джона Роббинса связанный в Ответ Майкла Мэддокса это как бы выскочило на меня:

База данных .NET PDB содержит только две части информации: имена исходных файлов и их строки и имена локальных переменных .Вся остальная информация уже содержится в метаданных .NET, поэтому нет необходимости дублировать ту же самую информацию в файле PDB.

На мой взгляд, это подтверждает то, что другие говорили о Reflector, подразумевая, что реальная проблема заключается в доступе к сборкам.Как только это будет определено, единственное решение, которое нужно принять в отношении PDF-файлов, заключается в том, заботитесь ли вы о предоставлении имен файлов, номеров строк и имен локальных переменных (при условии, что вы изначально не показываете трассировки стека конечным пользователям).Или я слишком сильно все упростил?

Answer 1

Вот еще один вопрос, на который стоит обратить внимание:

Существуют ли какие-либо проблемы с безопасностью, оставляющие файлы отладки PDB на действующих серверах?

И дополнительная информация о файлах PDB:

Файлы PDB:Что Должен знать Каждый разработчик

Как правило, я всегда включаю pdb-файлы в свои развертывания, выигрыш слишком велик, чтобы его игнорировать.

Если вы никогда не предоставляете трассировку стека своим пользователям (а обычно этого делать не следует), то на самом деле никаких дополнительных рисков для безопасности при развертывании файлов PDB нет.

Когда происходит видимая пользователем трассировка стека, пользователь может видеть полную трассировку стека, включая имя вашего файла и номера строк файла.Это могло бы дать им некоторое представление об архитектуре вашего приложения, что потенциально помогло бы им в случае взлома.

Более серьезная угроза безопасности - это что-то вроде Отражатель который при использовании в ваших библиотеках DLL позволит им просматривать ваш исходный код, с файлами pdb или без них.

Answer 2

Если вы выполняете развертывание в производственной среде своей собственной организации, то это не проблема безопасности.

Если вы продаете свое программное обеспечение другим организациям, то файл .pdb может помочь кому-то, заинтересованному в обратном инжиниринге, - для вас это может быть проблемой, а может и не быть.

Однако (чтобы было понятно), вы не хотите, чтобы ваши трассировки стека отображались клиенту - независимо от того, доступны файлы .pdbs или нет.Но если вы просто регистрируете трассировки и представляете клиенту "красивую" страницу с ошибкой, это не проблема.

Answer 3

Имея отладочные символы, злоумышленник может определить глобальные переменные, смещения функций и т.д., Представляющие интерес.

Чтобы он мог видеть, что в вашей системе есть такая функция, как:

AddAdminUser(string name, string password);

И знать его смещение.Если ваша программа скомпрометирована, он может вызвать эту функцию, чтобы предоставить себе права администратора.

Или что-то вроде:

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

И знает, какой бит нужно щелкнуть, чтобы перевести ваше приложение в небезопасный режим.

В качестве альтернативы, для выяснения этого потребовалось бы довольно много времени на обратный инжиниринг.Однако это не является непреодолимым промежутком времени.

Но ...все это означает, что ваш злоумышленник уже находится в положении, когда он может скомпрометировать вашу программу.Если это так, то вы уже проиграли.

Если у вас есть веские деловые причины для развертывания символов pdb, продолжайте.Развертывание PDB не сделает вас небезопасным.Если у вас нет веских причин для развертывания, вам не следует этого делать, так как это немного облегчит атаки.

Вы также можете создавать общедоступные PDB-файлы - они удаляют определенные фрагменты информации, но дают вам достаточно символов для создания трассировки стека и выполнения базовой отладки.Детали таковы здесь.Корпорация Майкрософт развертывает общедоступные PDB-базы данных на своем сервере symbol server для всеобщего использования.

Редактировать:Большая часть того, что я сказал, относится к проблемам, связанным с развертыванием PDB для машинного кода - я думаю, что многие из этих проблем люди переносят и на .NET, хотя метаданные assembly уже передают довольно много этого.

Answer 4

Кто-нибудь может "восстановить" полный исходный код вашего приложения.Если это с открытым исходным кодом, вам не нужно беспокоиться.Если у него есть какой-то IP (алгоритмы, защита, лицензии), это, вероятно, не очень хорошая идея.

Это правда, что такие инструменты, как Reflector, могут реконструировать части вашего кода даже без файлов PDB, но запутывания могут помочь (ну, совсем немного).