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

Question

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

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

РЕДАКТИРОВАТЬ: последующие вопросы / разъяснения

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

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

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

Answer 1

Вот еще один вопрос:

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

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

AddAdminUser(string name, string password);

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

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

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

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

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

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

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

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

РЕДАКТИРОВАТЬ: Большинство из того, что я сказал, относится к проблемам, связанным с развертыванием PDB для собственного кода - я думаю, что многие из этих проблем люди переносят и на .NET, даже несмотря на то, что метаданные ассемблера уже передают довольно много этого.

Answer 4

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

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