Jakie jest ryzyko wdrożenia symboli debugowania (pliku pdb) w środowisku produkcyjnym?

Mam aplikację, która rejestruje ślady ciągów wyjątków i chciałem, aby te ślady stosu zawierały nazwy plików i numery wierszy podczas wdrażania w środowisku produkcyjnym. Wymyśliłem, jak wdrożyć symbole debugowania w zestawie, ale w trakcie badania problemu natknąłem się na to pytanie , co oznacza, że ​​nie jest dobrym pomysłem włączanie plików pdb w środowisku produkcyjnym. Komentarz do zaakceptowanej odpowiedzi brzmi: „... informacje debugowania mogą ujawnić poufne dane i stanowić wektor ataku. W zależności od tego, jaka jest Twoja aplikacja”.

Więc jakie wrażliwe dane mogą zostać ujawnione? W jaki sposób można użyć symboli debugowania do złamania zabezpieczeń aplikacji? Jestem ciekawy szczegółów technicznych, ale tak naprawdę szukam praktycznego sposobu oceny ryzyka włączenia symboli debugowania dla dowolnej aplikacji i środowiska produkcyjnego. Albo inaczej: co najgorszego może się wydarzyć?

EDYCJA: pytanie uzupełniające / wyjaśnienie

Na podstawie dotychczasowych odpowiedzi wszystkich wydaje się, że to pytanie można nieco uprościć w przypadku aplikacji .NET. Ten fragment z bloga Johna Robbinsa, do którego link znajduje się w odpowiedzi Michaela Maddoxa, rzucił się we mnie:

.NET PDB zawiera tylko dwie informacje, nazwy plików źródłowych i ich wiersze oraz lokalne nazwy zmiennych. Wszystkie inne informacje znajdują się już w metadanych .NET, więc nie ma potrzeby powielania tych samych informacji w pliku PDB.

Dla mnie to powtórzenie tego, co inni mówili o Reflector, z implikacją, że prawdziwym problemem jest dostęp do zgromadzeń. Po ustaleniu jedyną decyzją, jaką należy podjąć w odniesieniu do PDB, jest to, czy zależy Ci na ujawnianiu nazw plików, numerów wierszy i lokalnych nazw zmiennych (zakładając, że na początku nie pokazujesz śladów stosu użytkownikom końcowym). A może zbytnio to uprościłem?

Oto kolejne pytanie, którym należy się przyjrzeć:

Czy są jakieś problemy z bezpieczeństwem pozostawiające pliki debugowania PDB na serwerach na żywo?

Więcej informacji o plikach PDB:

Pliki PDB: co każdy programista musi wiedzieć

Ogólnie rzecz biorąc, zawsze dołączam pliki pdb do moich wdrożeń, korzyści są zbyt duże, aby je zignorować.

Jeśli nigdy nie ujawniasz śladu stosu swoim użytkownikom (i generalnie nie powinieneś), tak naprawdę nie ma żadnego dodatkowego zagrożenia bezpieczeństwa związanego z wdrażaniem plików PDB.

Gdy pojawi się widoczny dla użytkownika ślad stosu, użytkownik może zobaczyć pełny ślad stosu, w tym nazwę pliku i numery wierszy pliku. Może to dać im wyobrażenie o tym, jak zaprojektowana jest Twoja aplikacja, co mogłoby im pomóc w przypadku włamania.

Większym zagrożeniem dla bezpieczeństwa jest coś w rodzaju Reflectora, które użyte na twoich bibliotekach DLL pozwoli im przeglądać twój kod źródłowy, z plikami pdb lub bez nich.

Jeśli wdrażasz w środowisku produkcyjnym we własnej organizacji, nie jest to problem z bezpieczeństwem.

Jeśli sprzedajesz swoje oprogramowanie innym podmiotom, plik .pdb może dać szansę osobie zainteresowanej inżynierią wsteczną - to może, ale nie musi, stanowić dla Ciebie problem.

Jednak (dla jasności) nie chcesz, aby ślady stosu były wyświetlane klientowi - niezależnie od tego, czy plik .pdbs jest dostępny, czy nie. Ale jeśli tylko rejestrujesz ślady i prezentujesz klientowi „ładną” stronę błędu, nie stanowi to problemu.

Posiadając symbole debugowania, atakujący może określić zmienne globalne, przesunięcia funkcji itp.

Więc mógł zobaczyć, że twój system ma funkcję:

AddAdminUser(string name, string password);

I znać jego przesunięcie. Jeśli twój program jest zagrożony, mógłby wywołać tę funkcję, aby nadać sobie uprawnienia administratora.

Lub coś takiego:

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

I wie, co przesunąć, aby przełączyć aplikację w niezabezpieczony tryb.

Alternatywnie, rozwiązanie tego wymagałoby sporo czasu na inżynierię wsteczną. Nie jest to jednak czas nie do pokonania.

Ale . . . to wszystko oznacza, że ​​atakujący jest już w pozycji, w której może złamać twój program. Jeśli tak jest, już przegrałeś.

Jeśli masz dobry powód biznesowy, aby wdrożyć symbole PDB, śmiało. Wdrażanie PDB nie sprawi, że poczujesz się niepewnie. Jeśli nie masz dobrego powodu do rozstawienia się, nie powinieneś tego robić, ponieważ może to nieco ułatwić ataki.

Możesz także tworzyć publiczne pliki PDB - usuwają one niektóre informacje, ale dają wystarczającą liczbę symboli, aby wygenerować ślad stosu i przeprowadzić podstawowe debugowanie. Szczegóły tutaj . Firma Microsoft wdraża publiczne PDB na swoim serwerze symboli, aby wszyscy mogli z nich korzystać.

EDYCJA: Większość z tego, co powiedziałem, odnosi się do obaw związanych z wdrażaniem plików PDB dla kodu natywnego - myślę, że wiele z nich przenosi się również do .NET, mimo że metadane asemblera już wiele tego przekazują.

Ktoś może „przywrócić” cały kod źródłowy Twojej aplikacji. Jeśli jest to Open Source, nie musisz się martwić. Jeśli ma jakieś IP (algorytmy, zabezpieczenia, licencje) to prawdopodobnie nie jest to dobry pomysł.

Prawdą jest, że narzędzia takie jak Reflector mogą rekonstruować części twojego kodu nawet bez plików PDB, ale zaciemnianie może pomóc (cóż, tylko trochę).