gdb, MySQL - luźne przemyślenia

Przeglądając ostatnio kod exploita dla serwera MySQL moją uwagę przyciągnął komentarz :

suse11:~ # gdb -q
(gdb) att 5542
Attaching to process 5542
Reading symbols from /var/mysql/libexec/mysqld...cdone.
...

0xffffe430 in __kernel_vsyscall ()
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6bbab90 (LWP 5545)]
0x41424344 in ?? ()

Pokazuje to ciekawy trend: w systemach wywodzących się z Unixa, gdb nadal jest preferowanym narzędziem do monitorowania atakowanych procesów. Nie byłoby by w tym nic dziwnego – przecież gdb jest debugerem, ale dla kontrastu: w przypadku platformy Windows, dzisiaj stosuje się wyspecjalizowane narzędzia do tego typu zadań. Niech za przykład posłuży Immunity Debgger (bazujący na doskonałym OllyDBG). Nawet Microsoft dostrzegł potrzebę wyspecjalizowanych funkcji w debugerze i do swojego produktu: WinDBG dodaje przydatne rozszerzenie o nazwie !exploitable (http://www.codeplex.com/msecdbg ). O ile w tym zakresie dla systemów Win32/64 dokonał się duży postęp na przestrzeni ostatnich kilku lat, to platformy o otwartym kodzie źródłowym pozostały z jakiegoś powodu w tyle.

Oczywiście zaletą gdb jest fakt iż jest on dostępny praktycznie w każdym systemie Linux, BSD, Unix. Jednak co do wygody korzystania z niego zdania są podzielone. Oczywiście można wykorzystać świetny debugger z pakietu IDA Pro i monitorować atakowany proces nawet zdalnie. Jednak IDA Pro niestety nie działa na każdej platformie. Powyższa sytuacja może okazać się czasem problematyczna. Na przykład kompleksowy fuzzing wymaga monitorowania testowanego obiektu. Oczywiście jeśli mamy zadowolić się tylko informacją o tym, że znaleźliśmy taki ciąg danych wejściowych który powoduje załamanie wątku / procesu to nie ma problemu. Jednak w przypadku produkcji exploita który jeszcze powinien być stabilny każde narzędzie usprawniające ten proces oznacza istotną pomoc. Powyższe spostrzeżenia są o tyle ciekawe że korzeni takich mechanizmów jak security cookie (przełącznik /GS w VisualStudio) czy DEP trzeba szukać właśnie w platformach z rodziny Unix/Linux. W przypadku OpenBSD w którym praktycznie wszystko jest randomizowane aby utrudnić (przynajmniej w teorii) proces penetracji, korzysta z modułu SYS TRACE i ochrony stosu dzisiaj nadal korzystamy z gdb. Jednak wraz ze wzrostem skomplikowania zabezpieczeń otwarty kod źródłowy nie będzie stanowił o przewadze. Fuzzer zawsze wykona więcej testów niż człowiek analizujący kod. Oznacza to także, że w przyszłości gdb może nie być wystarczającym narzędziem dla poszukiwaczy nowych podatności.