Який ризик розгортання символів налагодження (файл pdb) у виробничому середовищі?

У мене є програма, яка реєструє траси винятків, і я хотіла, щоб ці траси стека включали імена файлів та номери рядків під час розгортання у виробництві. Я розібрався, як розгорнути символи налагодження зі збіркою, але в процесі дослідження проблеми я зіткнувся з цим питанням , що означає, що недобре включати файли pdb у виробниче середовище. У коментарі до прийнятої відповіді сказано: "... інформація про налагодження може видавати конфіденційні дані та бути вектором атаки. Залежно від того, який ваш додаток".

То який тип конфіденційних даних може бути відкритий? Як можна використовувати символи налагодження для компрометації програми? Мені цікаво щодо технічних деталей, але те, що я насправді шукаю, - це практичний спосіб оцінити ризик включення символів налагодження для будь-якого даного додаткового та виробничого середовища. Або по-іншому: що найгірше може статися?

EDIT: подальше запитання / роз’яснення

Отже, виходячи з відповідей усіх на сьогодні, здається, це питання можна дещо спростити для програм .NET. Цей фрагмент із блогу Джона Роббінса, зв’язаний із відповіддю Майкла Меддокса, вискочив мені:

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

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

Ось ще одне запитання, на яке слід поглянути:

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

І більше інформації про файли PDB:

Файли PDB: Що повинен знати кожен розробник

Взагалі, я завжди включаю файли pdb у свої розгортання, прибуток занадто великий, щоб їх ігнорувати.

Якщо ви ніколи не надаєте своїм користувачам трасування стека (і, як правило, цього не слід робити), насправді не існує додаткового ризику безпеки для розгортання файлів PDB.

Коли трапляється видима трасування стека, користувач може побачити повну трасу стека, включаючи ім'я вашого файлу та номери рядків файлів. Це може дати їм деяке уявлення про те, як сконструйовано ваш додаток, що потенційно може допомогти їм у випадку злому.

Більшою загрозою для безпеки є щось на зразок Reflector, який при використанні у ваших бібліотеках DLL дозволить їм переглядати ваш вихідний код із файлами PDB або без них.

Якщо ви використовуєте виробниче середовище у власній організації, це не проблема безпеки.

Якщо ви продаєте своє програмне забезпечення іншим організаціям, тоді файл .pdb може дати комусь, хто зацікавлений у зворотному конструюванні, відмовитись - це може бути проблемою для вас чи не.

Однак (щоб було зрозуміло), ви не хочете, щоб ваші сліди стека відображалися клієнту - незалежно від того, доступні .pdbs чи ні. Але якщо ви просто реєструєте траси і представляєте клієнтові "помилкову" сторінку помилок, це не проблема.

Маючи символи налагодження, зловмисник може визначати загальні змінні, зміщення функцій тощо, що цікавить.

Тож він бачив, що у вашій системі є така функція, як:

AddAdminUser(string name, string password);

І знати його компенсацію. Якщо ваша програма скомпрометована, він може викликати цю функцію, щоб надати собі права адміністратора.

Або щось на зразок:

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

І знає, який біт гортати, щоб перевести вашу програму в незахищений режим.

Як варіант, для цього знадобиться досить багато часу зворотного проектування. Однак не непереборної кількості часу.

Але. . . все це означає, що ваш зловмисник уже в такому положенні, що він може скомпрометувати вашу програму. Якщо це так, ви вже програли.

Якщо у вас є вагома ділова причина для розгортання символів PDB, продовжуйте. Розгортання PDB не зробить вас небезпечним. Якщо у вас немає вагомих причин для розгортання, не слід цього робити, оскільки це трохи полегшить атаки.

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

EDIT: Більшість з того, що я сказав, стосується проблем, пов’язаних із розгортанням PDB для власного коду - я думаю, що багато з цих проблем також переносяться на .NET, навіть незважаючи на те, що метадані збірки вже передають досить багато цього.

Хтось може «відновити» повний вихідний код вашої програми. Якщо це Open Source, вам не потрібно турбуватися. Якщо у нього є деякі ІР (алгоритми, захист, ліцензії), це, мабуть, не є гарною ідеєю.

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