1. Wprowadzenie
2. Budowa jądra ze wsparciem dla PaX
3. Modyfikacje jądra wprowadzone przez PaX
3.1 Ochrona kodu wykonywalnego
3.1.1 Wprowadzenie
3.1.2 Podział ESP w PaX
3.2 Losowe rozmieszczenie obszarów pamięci (ASLR)
4. PaX a błąd przepełnienia bufora
5. Przed czym PaX nie chroni do końca
6. Kiedy PaX nie jest dobrym pomysłem
7. Bibliografia
Większość niebezpieczeństw związanych z oprogramowaniem ma swoje korzenie w błędach, które popełniają programiści. Błędy te często pojawiają się we fragmentach, kodu, które odpowiadają za interakcję z użytkownikiem (np. pobranie od użytkownika pewnej porcji danych). W ich wyniku wprawny użytkownik może próbować zaatakować system próbując:
PaX jest łatą na jądro systemu operacyjnego Linux, która w dość skuteczny sposób chroni przed tego typu atakami, a właściwie przed możliwością ich przeprowadzenia. PaX nie stara się szukać i naprawiać błędów popełnionych przez programistę. Jego główne działanie opiera się na:
Aby zainstalować PaX należy zainstalować na aktualne jądro odpowiednią łatę (pobraną z http://pax.grsecurity.net) a następnie uruchomić standardową kofigurację. W sekcji
Security Options -> PaX
dostępne będą następujące opcje:
[*] Enable various PaX features
PaX Control ->
[ ] Support soft mode
[*] Use legacy ELF header marking
[*] Use ELF program header marking
MAC system integration (none) --->
Non-executable page ->
[*] Enforce non-executable pages
[*] Paging based non-executable pages
[*] Segmentation based non-executable pages
[*] Emulate trampolines
[*] Restrict mprotect()
[ ] Disallow ELF text relocations
Address Space Layout Randomization ->
[*] Address Space Layout Randomization
[*] Randomize kernel stack base
[*] Randomize user stack base
[*] Randomize mmap() base
[*] Randomize ET_EXEC base
Po wybraniu odpowiednich opcji pozostaje skompilowanie jądra i umieszczenie go w katalogu /boot.
Główną cechą PaX jest wprowadzenie ochrony obszarów pamięci, w których znajduje się kod wykonywalny (Executable Space Protection). Różnice między pamięcią chronioną i nie chronioną przedstawiają następujące rysunki:
Powyższy rysunek przedstawia przestrzeń pamięci procesu bez ESP. W tym przypadku cała pamięć procesu może być zapisywana jak również być źródłem kodu wykonywalnego. W rezultacie, proces sam może podmieniać swój kod (wpisując go w odpowiednie miejsce pamięci).
Powyższy rysunek przedstawia przestrzeń pamięci procesu z włączoną funkcją ESP. Widać, że każdy (zajęty) fragment pamięci jest jednoznacznie sklasyfikowany jako wykonywalny lub zapisywalny. W tej sytuacji proces nie ma możliwości podmiany kodu - taka próba zostałaby wykryta i zakończyłaby się niepowodzeniem (prawdopodobnie zakończeniem procesu).
W architekturach, w których jest dostępny, ESP wykorzystuje do ochrony bit NX (Non-eXecutable), jeżeli bit ten nie jest dostępny PaX go emuluje. Domyślnie system operacyjny Linux wykorzystuje bit NX do odpowiedniej ochrony pamięci, tak więc obszar pamięci programu wygląda tak jak na rysunku 2. Jednak nic nie stoi na przeszkodzie, aby program sam dokonywał zmian w tym obszarze i w rezultacie jego obszar pamięci może wyglądać tak jak na rysunku 1. Zadaniem PaX jest zapobieganie takim właśnie zmianom przestrzeni adresowej oraz takie ustawianie uprawnień dostępu do pamięci, aby program wykonał się poprawnie, ale aby nie było możliwe zrobienie niczego więcej (jest to tzw. zasada minimalnych uprawnień).
Jeżeli program w trakcie swojego działania modyfikuje jakiś obszar swojej pamięci, PaX dba o to, aby ten obszar nigdy "nie był wykonywany". W rezultacie nie jest możliwe wykonanie kodu znajdującego się w obszarze pamięci, do którego proces cos zapisywał, dopóki obszar ten nie zostanie zwolniony.
Jednak w niektórych przypadkach takie zabezpieczenie wydaje się być zbyt restrykcyjne - istnieją programy, które do poprawnego działania wymagają generowania kodu do wykonania w trakcie działania. Jednak większość takich programów może zostać zmodyfikowana i radzić sobie bez generowania kodu "on-line". Jeżeli taka możliwośc nie wchodzi w grę (np. program należy do tej "mniejszości" której nie da się zmodyfikować), PaX oferuje administratorowi systemu opcję wyłączenia omówionych wcześniej ograniczeń.
Ochrona kodu wykonywalnego (NOEXEC) została w PaX podzielona na 2 części:
Ta modyfikacja wprowadza ochronę przed atakami, które opierają się na pewnej wiedzy na temat rozmieszczenia poszczególnych obszarów w przestrzeni adresowej procesu. Po jej włączeniu PaX losowo rozmieszcza wybrane obszary pamieci (zawsze dotyczy to stosu i sterty, opcjonalnie można też kazać PaX'owi "przemieszać" inne obszary). Przykładowa przestrzeń adresowa procesu uruchomionego w systemie z włączoną opcją ASLR może wyglądać wiec tak:
Po zastosowaniu ASLR, jedyne co pozostaje potencjalnemu intruzowi to "strzelanie" w adresy pamięci i sprawdzanie czy tam akurat znajduje się to czego szuka. Takie operacje (w przypadku niepowodzenia) powodują jednak wystąpienie błędów, które w rezultacie najprawdopodobniej zakończą atakowany proces. Ten sam proces po ponownym uruchomieniu będzie miał (dzięki ASLR) inaczej zorganizowaną pamięć, w wyniku czego intruzowi nie pomoże żadna wiedza zdobyta przy poprzednim ataku. Ponadto duża ilość "strzałów" w pamięć procesu jest łatwo wykrywalna (pojawia się dużo "crash'ów" procesu), a to z kolei obniża skuteczność tego typu ataków.
PaX nie jest nakładką, która ma wykrywać i zapobiegać samemu wystąpieniu błędu przepełnienia bufora. Jego głównym celem jest ochrona przed tym, co może nastąpić, gdy taki błąd już wystąpi. Najczęstszym sposobem wykorzystania omawianego błędu jest zmuszenie atakowanego komputera do wykonywania podstawionego kodu (i uzyskanie np. dostępu do systemu na prawach administratora).
Przeanalizujmy sposoby, na które intruz może próbować podstawić jakiś "obcy" kod i jak radzi sobie z tym PaX :
Skutecznie wykorzystując kontrolę uprawnień dostępu do pamięci, PaX jest jednym z niewielu narzędzi, które gwarantuje 100% skuteczność, jeżeli chodzi o ochronę przed wykonywaniem podstawionego kodu. Jednak istnieją ataki, przed którymi PaX nie daje juz 100% zabezpieczenia. Mowa tu o atakach, które swoje działanie opierają na pewnej wiedzy na temat przestrzeni adresowej procesu. Implementowany w PaX ASLR zabezpiecza system w takim sensie, że utrudnia włamanie się do systemu. Wprowadzając randomizację pamięci skazujemy potencjalnego intruza na dużo dłuższą i łatwiej wykrywalną próbę ataku. Ten jest jednak możliwy i w przypadku "zgadnięcia" odpowiedniego adresu pamięci - w pełni skuteczny.
Podobnie, korzystając z PaX nie zapewnimy ochrony przed atakami, które opierają się na wykorzystaniu już istniejącego kodu, ale w zamierzeniach autorów nie to było celem powstania omawianej łaty.
Mimo bardzo skutecznej ochrony przed wykonywaniem podstawionego kodu, PaX ma swoje wady. Próba przeprowadzenia ataku kończy się zazwyczaj "wywaleniem się" atakowanego procesu. Jeżeli jest to proces istotny dla całego systemu, może to spowodować przerwę w jego pracy, a to może pociągnąć za sobą np. niedostępność witryny internetowej, za obsługę której ów system odpowiadał. W niektórych przypadkach takie zdarzenie nie jest akceptowalne - witryna internetowa może należeć do sklepu internetowego, więc jej niedostępność przekłada się na rzeczywiste straty finansowe. Rozważając użycie PaX należy się zastanowić, czy ważniejsze jest ciągłe i stabilne działanie systemu, czy absolutne bezpieczeństwo danych. PaX zdaje się być bardzo dobrym rozwiązaniem w tym drugim przypadku, gdyż w razie ewntualnego ataku żadne dane nie są kopiowane na zewnątrz.
http://en.wikipedia.org/wiki/PaX
http://pax.grsecurity.net/docs/pax.txt
http://pax.grsecurity.net/docs/noexec.txt
http://pax.grsecurity.net/docs/aslr.txt