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

81

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?

Matt
źródło
@Matt: Czy to jest aplikacja komputerowa, internetowa, kompaktowa czy ...?
Kb.
@Kb - w tym konkretnym przypadku jest to aplikacja konsolowa, którą uruchamiamy z harmonogramem. Został opracowany we własnym zakresie do użytku wewnętrznego, więc każdy, kto może zobaczyć plik pdb, będzie mógł również zobaczyć kod źródłowy, więc nie martwię się zbytnio o tę konkretną aplikację. Bardziej interesuje mnie przypadek ogólny / praktyczny, więc mogę zdecydować, czy zaryzykować z innymi aplikacjami, takimi jak np. Aplikacja komputerowa zainstalowana na laptopach, które są czasami połączone z poufnymi danymi w naszej sieci.
Matt

Odpowiedzi:

58

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.

Michael Maddox
źródło
3
Dzięki za linki. Wygląda więc na to, że przynajmniej część równania dotyczy miejsca, w którym aplikacja jest wdrażana (tj. Komputer stacjonarny a serwer WWW).
Matt,
15

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.

Michael Burr
źródło
Wierzę, że Matt mówi o .Net. Jakie dodatkowe informacje można uzyskać z PDB, a które nie są już dostępne za pośrednictwem narzędzia takiego jak Reflektor Lutza?
Lars Truijens
Natychmiast przychodzą do głowy informacje o źródle i linii. Nie sądzę, aby w metadanych były obecne lokalne nazwy zmiennych.
Michael
@Lars - nigdy nie powiedziałem, że to pomoże :) Myślę, że cały ten strach wokół PDB i inżynierii odwrotnej jest bardzo źle ulokowany. Osoba, która może użyć PDB do inżynierii wstecznej, może użyć porządnego deasemblera, który obsługuje adnotacje.
Michael
1
Widzę, jak lokalne nazwy zmiennych w bardzo długich metodach mogą pomóc w inżynierii wstecznej, ale nazwy plików źródłowych i informacje o wierszach? To nie jest realne ryzyko w porównaniu z narzędziami takimi jak Reflector, jeśli o mnie chodzi :)
Lars Truijens
1
@Lars - Myślę, że innym sposobem wyrażenia tego, co Michael Maddox i ja mówimy, jest to, że przekazanie pliku .pdbs komuś, kto ma zgromadzenia, często nie jest tak naprawdę zagrożeniem dla bezpieczeństwa. Udostępnienie śladu stosu komuś, kto nie ma zestawów, może być.
Michael Burr
11

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ą.

Michael
źródło
6
Myślę, że Matt mówi o .Net. Możesz już pobrać całe źródło z narzędzia takiego jak Lutz 'Reflector, nawet bez PDB.
Lars Truijens
@Lars - zaktualizowałem mój komentarz, aby wskazać, że większość to kod natywny. Myślę, że wiele osób po prostu obawia się irracjonalnie, że PDB umożliwiają inżynierię wsteczną i uważają, że napastnicy nie wiedzą, jak używać dezasemblerów, takich jak IDA Pro. Uważam, że te obawy są również nieprawidłowo wprowadzane do kodu zarządzanego.
Michael
2

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ę).

db_
źródło
1
Myślę, że Matt mówi o .Net. Możesz już pobrać całe źródło z narzędzia takiego jak Lutz Reflector, nawet bez PDB.
Lars Truijens
Lars, całkowicie się zgadzam, Reflector to świetne narzędzie do inżynierii odwrotnej. Ale czasami kod wynikowy nie jest zbyt czytelny, zwłaszcza jeśli źródło zostało zaciemnione. Pliki PDB uczynią życie jeszcze lepszym.
db_