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

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

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

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

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

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

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

Ответ 1

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

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

И больше информации о файлах PDB:

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

AddAdminUser(string name, string password);

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

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

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

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

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

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

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

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

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

Ответ 4

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

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