Tarcza egzekucyjna

Exec Shield to projekt rozpoczęty w firmie Red Hat , Inc pod koniec 2002 roku w celu zmniejszenia ryzyka robaków lub innych automatycznych ataków zdalnych na systemy Linux. Pierwszym rezultatem projektu była bezpieczeństwa dla jądra Linuksa , która emuluje bit NX na procesorach x86 , które nie mają natywnej sprzętowej implementacji NX. Chociaż projekt Exec Shield składał się z wielu innych elementów, niektórzy nazywają ten pierwszy patch Exec Shield.

Pierwsza łatka Exec Shield próbuje oznaczyć pamięć danych jako niewykonywalną, a pamięć programu jako niemożliwą do zapisu. Powstrzymuje to wiele luk w zabezpieczeniach , takich jak te wynikające z przepełnienia bufora i innych technik polegających na nadpisaniu danych i wstawieniu kodu do tych struktur. Exec Shield zapewnia również pewną losowość układu przestrzeni adresowej dla mmap () i podstawy sterty.

Łatka dodatkowo zwiększa trudność wstawiania i wykonywania kodu powłoki , czyniąc większość exploitów nieskutecznymi. Do pełnego wykorzystania exec-shield nie jest konieczna ponowna kompilacja aplikacji, chociaż niektóre aplikacje ( Mono , Wine , XEmacs , Mplayer ) nie są w pełni kompatybilne.

Inne funkcje, które wyszły z projektu Exec Shield, to pliki wykonywalne niezależne od pozycji (PIE), łatka losowej przestrzeni adresowej dla jąder Linuksa, szeroki zestaw wewnętrznych kontroli bezpieczeństwa glibc, które prawie uniemożliwiają wykorzystywanie sterty i ciągów znaków formatu, GCC Fortify Source oraz port i połączenie funkcji ochrony stosu GCC .

Realizacja

Exec Shield działa na wszystkich procesorach x86 z wykorzystaniem limitu segmentu kodu. Ze względu na sposób działania Exec Shield jest bardzo lekki; jednak nie zapewni to pełnej ochrony dowolnych pamięci wirtualnej . Jeśli limit CS zostanie podniesiony, na przykład przez wywołanie mprotect() w celu wykonania większej ilości pamięci, wówczas zabezpieczenia zostaną utracone poniżej tego limitu. Ingo Molnar zwraca na to uwagę w rozmowie e-mailowej. Większość aplikacji jest w tym całkiem rozsądna; stos (ważna część) przynajmniej kończy się nad wszelkimi zmapowanymi bibliotekami, więc nie staje się wykonywalny, z wyjątkiem jawnych wywołań aplikacji.

Od sierpnia 2004 r. żaden z projektów Exec Shield nie próbował wymusić ochrony pamięci poprzez ograniczenie mprotect () na dowolnej architekturze; chociaż pamięć może początkowo nie być wykonywalna, może później stać się wykonywalna, więc jądro pozwoli aplikacji na jednoczesne oznaczanie stron pamięci jako zapisywalnych i wykonywalnych. Jednak we współpracy z Security-Enhanced Linux (SELinux), standardowa polityka dla dystrybucji Fedora Core zabrania takiego zachowania większości plików wykonywalnych, z kilkoma wyjątkami ze względu na kompatybilność.

Historia

Exec Shield został opracowany przez różne osoby w firmie Red Hat; pierwsza łatka została wydana przez Ingo Molnara z Red Hat i wydana po raz pierwszy w maju 2003. Jest częścią Fedory Core 1 do 6 i Red Hat Enterprise Linux od wersji 3. Inne zaangażowane osoby to Jakub Jelínek, Ulrich Drepper, Richard Henderson i Arjan van de Ven.

Zobacz też

^ „Uwagi do wydania Fedory Core 1” . Red Hat, Inc. Listopad 2003. Zarchiwizowane od oryginału w dniu 2003-12-02 . Źródło 2007-10-18 .
^ van de Ven, Arjan (sierpień 2004). „Nowe ulepszenia zabezpieczeń w systemie Red Hat Enterprise Linux v.3, aktualizacja 3” (PDF) . Red Hat, Inc. Zarchiwizowane od oryginału (PDF) w dniu 12.05.2005 . Źródło 2007-10-18 .

Linki zewnętrzne

Strona internetowa łatki Exec Shield Ingo Molnara zawiera dokumentację w pliku ANNOUNCE-exec-shield
Artykuł w Newsforge
Artykuł magazynu Red Hat/artykuł projektu
Negatywne problemy z bezpieczeństwem z ExecShield

[1] „Uwagi do wydania Fedory Core 1” . Red Hat, Inc. Listopad 2003. Zarchiwizowane od oryginału w dniu 2003-12-02 . Źródło 2007-10-18 .

[2] van de Ven, Arjan (sierpień 2004). „Nowe ulepszenia zabezpieczeń w systemie Red Hat Enterprise Linux v.3, aktualizacja 3” (PDF) . Red Hat, Inc. Zarchiwizowane od oryginału (PDF) w dniu 12.05.2005 . Źródło 2007-10-18 .