Wykonywalna ochrona przestrzeni - Executable space protection

W bezpieczeństwa komputerowego , ochrony wykonywalny-space znaki pamięci regiony jak niewykonywalny tak, że próba wykonania kodu maszynowego w tych regionach spowoduje wyjątek . Wykorzystuje funkcje sprzętowe, takie jak bit NX ( bit no-execute), lub w niektórych przypadkach programowa emulacja tych funkcji. Jednak technologie, które w jakiś sposób emulują lub dostarczają bit NX, zazwyczaj nakładają mierzalne obciążenie; podczas używania bitu NX dostarczonego ze sprzętem nie nakłada się żadnych mierzalnych narzutów.

W Burroughs 5000 oferowane wsparcie sprzętowe dla zabezpieczenia wykonywalny przestrzeń na jego wprowadzenia w 1961 roku; ta zdolność pozostała w swoich następcach co najmniej do 2006 roku. W implementacji architektury tagowanej każde słowo pamięci miało powiązany, ukryty bit tagu oznaczający kod lub dane. W ten sposób programy użytkownika nie mogą pisać ani nawet czytać słowa programu, a słowa danych nie mogą być wykonywane.

Jeśli system operacyjny może oznaczyć niektóre lub wszystkie zapisywalne regiony pamięci jako niewykonywalne, może uniemożliwić wykonywanie obszarów pamięci stosu i sterty . Przyczynia się to do ochrony pewnych przepełnienie bufora czyny z następnych, w szczególności te, które wstrzykują i wykonania kodu, takich jak Sasser i Blaster robaki. Ataki te polegają na tym, że pewna część pamięci, zwykle stos, jest zarówno zapisywalna, jak i wykonywalna; jeśli nie, atak się nie udaje.

Wdrożenia systemu operacyjnego

Wiele systemów operacyjnych wdraża lub ma dostępne zasady ochrony przestrzeni wykonywalnej. Oto lista takich systemów w porządku alfabetycznym, każdy z technologiami uporządkowanymi od najnowszych do najstarszych.

W przypadku niektórych technologii dostępne jest podsumowanie zawierające główne funkcje obsługiwane przez każdą technologię. Podsumowanie ma następującą strukturę.

  • Obsługiwane sprzętowo procesory: (oddzielona przecinkami lista architektur procesorów)
  • Emulacja: (Nie) lub (Niezależna od architektury) lub (Lista oddzielonych przecinkami architektur procesorów)
  • Inne obsługiwane: (brak) lub (oddzielona przecinkami lista architektur procesorów)
  • Dystrybucja standardowa: (Nie) lub (Tak) lub (Oddzielona przecinkami lista dystrybucji lub wersji obsługujących tę technologię)
  • Data wydania: (data pierwszego wydania)

Technologia dostarczająca emulację Architecture Independent będzie działać na wszystkich procesorach, które nie są obsługiwane sprzętowo. Linia "Inne obsługiwane" jest przeznaczona dla procesorów, które pozwalają na niektóre metody szarego obszaru, gdzie nie istnieje wyraźny bit NX, ale sprzęt pozwala na jego emulację w pewien sposób.

Android

Począwszy od Androida 2.3 i nowszych, architektury, które go obsługują, mają domyślnie niewykonywalne strony, w tym niewykonywalny stos i stertę.

FreeBSD

Początkowe wsparcie dla bitu NX na procesorach x86-64 i IA-32 , które go obsługują, po raz pierwszy pojawiło się w FreeBSD -CURRENT 8 czerwca 2004 roku. Pojawiło się w wersjach FreeBSD od wydania 5.3.

Linux

Do jądra Linuksa wspiera NX bit na x86-64 i IA-32 procesorów, które go obsługują, jak nowoczesnych procesorów 64-bitowych wykonanych przez AMD, Intel, VIA i Transmeta. Wsparcie dla tej funkcji w trybie 64-bitowym na procesorach x86-64 zostało dodane w 2004 roku przez Andi Kleena , a później w tym samym roku Ingo Molnar dodał obsługę trybu 32-bitowego na procesorach 64-bitowych. Te funkcje są częścią głównej linii jądra Linuksa od czasu wydania jądra w wersji 2.6.8 w sierpniu 2004 roku.

Dostępność bitu NX w 32-bitowych jądrach x86, które mogą działać zarówno na 32-bitowych procesorach x86, jak i 64-bitowych procesorach zgodnych z IA-32, jest znacząca, ponieważ 32-bitowe jądro x86 normalnie nie oczekuje bitu NX że dostarcza AMD64 lub IA-64 ; łatka NX enabler zapewnia, że ​​te jądra będą próbowały użyć bitu NX, jeśli jest obecny.

Niektóre dystrybucje Linuksa dla komputerów stacjonarnych , takie jak Fedora , Ubuntu i openSUSE , nie włączają domyślnie opcji HIGHMEM64 w swoich domyślnych jądrach, co jest wymagane do uzyskania dostępu do bitu NX w trybie 32-bitowym, ponieważ tryb PAE jest wymagany do użycie bitu NX powoduje awarie rozruchu na procesorach starszych niż Pentium Pro (w tym Pentium MMX) oraz Celeron M i Pentium M bez obsługi NX. Inne procesory, które nie obsługują PAE to AMD K6 i wcześniejsze, Transmeta Crusoe , VIA C3 i wcześniejsze oraz Geode GX i LX. Wersje VMware Workstation starsze niż 4.0, Parallels Workstation starsze niż 4.0 oraz Microsoft Virtual PC i Virtual Server nie obsługują PAE na gościu. Fedora Core 6 i Ubuntu 9.10 i późniejsze dostarczają pakiet kernel-PAE, który obsługuje PAE i NX.

Ochrona pamięci NX zawsze była dostępna w Ubuntu dla wszystkich systemów, które miały sprzęt do jej obsługi i działały z 64-bitowym jądrem lub 32-bitowym jądrem serwera. 32-bitowe jądro pulpitu PAE (linux-image-generic-pae) w Ubuntu 9.10 i nowszych zapewnia również tryb PAE potrzebny do sprzętu z funkcją procesora NX. W przypadku systemów, w których brakuje sprzętu NX, 32-bitowe jądra zapewniają teraz przybliżenie funkcji procesora NX za pomocą emulacji oprogramowania, która może pomóc w zablokowaniu wielu exploitów, które atakujący może uruchomić ze stosu lub stosu pamięci.

Funkcjonalność non-execute była również obecna dla innych procesorów innych niż x86, obsługujących tę funkcjonalność w wielu wydaniach.

Tarcza Wykonawcy

Deweloper jądra Red Hat, Ingo Molnar, wydał łatkę jądra Linuksa o nazwie Exec Shield, aby przybliżyć i wykorzystać funkcjonalność NX na 32-bitowych procesorach x86. Łata Exec Shield została opublikowana na liście dyskusyjnej jądra Linuksa 2 maja 2003 r., ale została odrzucona ze względu na połączenie z jądrem podstawowym, ponieważ wiązała się z pewnymi nachalnymi zmianami w kodzie rdzenia w celu obsługi złożonych części emulacji. Obsługa starszych procesorów Exec Shield przybliża emulację NX, śledząc górny limit segmentu kodu. Nakłada to tylko kilka cykli narzutu podczas przełączania kontekstu, co jest praktycznie niemierzalne. W przypadku starszych procesorów bez bitu NX, Exec Shield nie chroni stron poniżej limitu segmentu kodu; wywołanie mprotect() oznaczające wyższą pamięć, taką jak stos, wykonywalny, oznaczy również całą pamięć poniżej tego limitu jako wykonywalną. Tak więc w takich sytuacjach schematy Exec Shield zawodzą. To jest koszt niskiego narzutu Exec Shield. Exec Shield sprawdza, czy występują dwa oznaczenia nagłówka ELF , które określają, czy stos lub sterta musi być wykonywalna. Są one nazywane odpowiednio PT_GNU_STACK i PT_GNU_HEAP. Exec Shield umożliwia ustawienie tych kontrolek zarówno dla plików wykonywalnych binarnych, jak i bibliotek; jeśli plik wykonywalny ładuje bibliotekę wymagającą złagodzenia danego ograniczenia, plik wykonywalny odziedziczy to oznaczenie i złagodzi to ograniczenie.

  • Obsługiwane sprzętowo procesory: wszystko, na czym Linux obsługuje NX
  • Emulacja: aproksymacja NX przy użyciu limitu segmentu kodu na IA-32 ( x86 ) i kompatybilna
  • Inne obsługiwane: brak
  • Dystrybucja standardowa: Fedora Core i Red Hat Enterprise Linux
  • Data wydania: 2 maja 2003 r.

Patena

Technologia PaX NX może emulować funkcjonalność NX lub używać sprzętowego bitu NX. PaX działa na procesorach x86, które nie mają bitu NX, takich jak 32-bit x86. Jądro Linux nadal nie jest dostarczane z PaX (stan na maj 2007); poprawkę należy scalić ręcznie.

PaX udostępnia dwie metody emulacji bitów NX, zwane SEGMEXEC i PAGEEXEC. Metoda SEGMEXEC nakłada mierzalny, ale niski narzut, zwykle mniejszy niż 1%, który jest stałym skalarem ponoszonym z powodu dublowania pamięci wirtualnej używanej do separacji między wykonywaniem a dostępem do danych. SEGMEXEC powoduje również zmniejszenie o połowę wirtualnej przestrzeni adresowej zadania, umożliwiając zadaniu dostęp do mniejszej ilości pamięci niż normalnie. Nie stanowi to problemu, dopóki zadanie nie wymaga dostępu do więcej niż połowy normalnej przestrzeni adresowej, co jest rzadkością. SEGMEXEC nie powoduje, że programy zużywają więcej pamięci systemowej (tj. RAM), ogranicza jedynie dostęp, do którego mają dostęp. Na 32-bitowych procesorach jest to 1,5 GB zamiast 3 GB.

PaX dostarcza metodę podobną do aproksymacji Exec Shield w PAGEEXEC jako przyspieszenie; jednak, gdy większa pamięć jest oznaczona jako wykonywalna, ta metoda traci swoje zabezpieczenia. W takich przypadkach PaX powraca do starszej metody opartej na zmiennych narzutach używanej przez PAGEEXEC do ochrony stron poniżej limitu CS, co może stać się dość kosztowną operacją w pewnych wzorcach dostępu do pamięci . Gdy metoda PAGEEXEC jest używana na procesorze dostarczającym sprzętowy bit NX, używany jest sprzętowy bit NX, a zatem nie ma znaczącego narzutu.

PaX dostarcza ograniczenia mprotect(), aby uniemożliwić programom oznaczanie pamięci w sposób, który tworzy pamięć użyteczną dla potencjalnego exploita . Ta zasada powoduje, że niektóre aplikacje przestają działać, ale można ją wyłączyć w przypadku programów, których dotyczy problem.

PaX umożliwia indywidualne sterowanie następującymi funkcjami technologii dla każdego pliku binarnego:

  • PAGEEXEC
  • SEGMEXEC
  • ograniczenia mprotect()
  • Emulacja trampoliny
  • Losowa baza wykonywalna
  • Randomizowana baza mmap()

PaX ignoruje zarówno PT_GNU_STACK, jak i PT_GNU_HEAP. W przeszłości PaX miał opcję konfiguracyjną honorującą te ustawienia, ale ta opcja została usunięta ze względów bezpieczeństwa, ponieważ uznano ją za nieprzydatną. Te same wyniki z PT_GNU_STACK można normalnie osiągnąć wyłączając ograniczenia mprotect(), ponieważ program normalnie mprotect() ładuje stos. Nie zawsze może to być prawdą; w sytuacjach, w których to się nie powiedzie, proste wyłączenie zarówno PAGEEXEC, jak i SEGMEXEC skutecznie usunie wszystkie ograniczenia przestrzeni wykonywalnej, dając zadaniu taką samą ochronę w jego przestrzeni wykonywalnej, jak w systemie innym niż PaX.

System operacyjny Mac

macOS for Intel obsługuje bit NX na wszystkich procesorach obsługiwanych przez Apple (od Mac OS X 10.4.4 – pierwszego wydania Intela – i dalej). Mac OS X 10.4 obsługiwał tylko ochronę stosu NX. W systemie Mac OS X 10.5 wszystkie 64-bitowe pliki wykonywalne mają stos i stertę NX; Ochrona W^X. Obejmuje to x86-64 (Core 2 lub nowszy) i 64-bitowy PowerPC na komputerach Mac G5 .

NetBSD

Począwszy od NetBSD 2.0 i późniejszych (9 grudnia 2004), architektury, które go obsługują, mają niewykonywalny stos i stertę.

Architektury, które mają na stronie ziarnistości składa się z: alfa , amd64 , hppa , i386 (z PAE ), powerpc (ibm4xx) SH5 , SPARC jest ( Sun4m , sun4d ) sparc64.

Architektury, które obsługują je tylko z granulacją regionu, to: i386 (bez PAE), inne powerpc (takie jak macppc).

Inne architektury nie korzystają z niewykonywalnego stosu lub sterty; NetBSD domyślnie nie używa żadnej emulacji programowej, aby oferować te funkcje na tych architekturach.

OpenBSD

Technologia w systemie operacyjnym OpenBSD , znana jako W^X, domyślnie oznacza zapisywalne strony jako niewykonywalne na procesorach, które to obsługują. W 32-bitowych procesorach x86 segment kodu jest ustawiony tak, aby obejmował tylko część przestrzeni adresowej, aby zapewnić pewien poziom ochrony przestrzeni wykonywalnej.

OpenBSD 3.3 został wydany 1 maja 2003 i jako pierwszy zawierał W^X.

  • Obsługiwane sprzętowo procesory: Alpha , AMD64 , HPPA , SPARC
  • Emulacja: IA-32 (x86)
  • Inne obsługiwane: brak
  • Dystrybucja standardowa: Tak
  • Data wydania: 1 maja 2003 r.

Solaris

Solaris obsługuje globalne wyłączanie wykonywania stosu na procesorach SPARC od wersji Solaris 2.6 (1997); w Solaris 9 (2002) dodano obsługę wyłączania wykonywania stosu dla każdego pliku wykonywalnego.

Okna

Począwszy od Windows XP Service Pack 2 (2004) i Windows Server 2003 Service Pack 1 (2005), funkcje NX zostały zaimplementowane po raz pierwszy na architekturze x86 . Ochrona przestrzeni wykonywalnej w systemie Windows nosi nazwę „Zapobieganie wykonywaniu danych” (DEP).

W systemie Windows XP lub Server 2003 ochrona NX była domyślnie używana wyłącznie na krytycznych usługach systemu Windows . Jeśli procesor x86 obsługiwał tę funkcję sprzętowo, to funkcje NX były domyślnie włączane automatycznie w systemie Windows XP/Server 2003. Jeśli funkcja nie była obsługiwana przez procesor x86, ochrona nie była zapewniona.

Wczesne implementacje DEP nie zapewniały randomizacji układu przestrzeni adresowej (ASLR), co umożliwiało potencjalne ataki typu „powrót do libc”, które można było wykorzystać do wyłączenia DEP podczas ataku. Dokumentacja PaX wyjaśnia, dlaczego ASLR jest konieczne; opracowano weryfikację koncepcji szczegółowo opisującą metodę, za pomocą której można obejść DEP w przypadku braku ASLR. Możliwe jest opracowanie udanego ataku, jeśli adres przygotowanych danych, takich jak uszkodzone obrazy lub pliki MP3, będzie znany osobie atakującej.

Microsoft dodał funkcjonalność ASLR w Windows Vista i Windows Server 2008 . Na tej platformie DEP jest realizowany poprzez automatyczne użycie jądra PAE w 32-bitowym systemie Windows oraz natywną obsługę jąder 64-bitowych. Funkcja funkcji DEP systemu Windows Vista działa, oznaczając pewne części pamięci jako przeznaczone do przechowywania tylko danych, które procesor obsługujący bity NX lub XD uznaje za niewykonywalne. W systemie Windows, począwszy od wersji Vista, czy funkcja DEP jest włączona lub wyłączona dla określonego procesu, można wyświetlić na karcie Procesy/Szczegóły w Menedżerze zadań systemu Windows .

System Windows implementuje programową funkcję DEP (bez użycia bitu NX) poprzez „Bezpieczną obsługę wyjątków strukturalnych” (SafeSEH) firmy Microsoft. W przypadku poprawnie skompilowanych aplikacji SafeSEH sprawdza, czy w przypadku wystąpienia wyjątku podczas wykonywania programu, procedura obsługi wyjątku jest zdefiniowana przez aplikację tak, jak została pierwotnie skompilowana. Efektem tej ochrony jest to, że atakujący nie jest w stanie dodać własnego programu obsługi wyjątków, który zapisał na stronie danych poprzez niesprawdzone dane wejściowe programu.

Gdy NX jest obsługiwany, jest domyślnie włączony. Windows pozwala programom kontrolować, które strony nie pozwalają na wykonanie poprzez jego API, jak również poprzez nagłówki sekcji w pliku PE . W interfejsie API dostęp środowiska wykonawczego do bitu NX jest ujawniany przez wywołania interfejsu API Win32 VirtualAlloc[Ex] i VirtualProtect[Ex] . Każda strona może być indywidualnie oznaczona jako wykonywalna lub niewykonywalna. Pomimo braku wcześniejszej obsługi sprzętu x86, ustawienia strony wykonywalnej i niewykonywalnej były dostępne od samego początku. W procesorach starszych niż NX obecność atrybutu „wykonywalny” nie ma żadnego wpływu. Został udokumentowany tak, jakby działał, w wyniku czego większość programistów używała go prawidłowo. W formacie pliku PE każda sekcja może określić swoją wykonalność. Flaga wykonania istnieje od początku formatu i standardowe linkery zawsze używały tej flagi poprawnie, nawet na długo przed bitem NX. Z tego powodu Windows może wymusić bit NX w starych programach. Zakładając, że programista zastosował się do „najlepszych praktyk”, aplikacje powinny działać poprawnie teraz, gdy NX jest faktycznie wymuszany. Tylko w kilku przypadkach wystąpiły problemy; Własny Microsoft .NET Runtime miał problemy z bitem NX i został zaktualizowany.

  • Obsługiwane sprzętowo Procesory: x86-64 (AMD64 i Intel 64), IA-64 , Efficeon , Pentium M (późniejsze wersje), AMD Sempron (późniejsze wersje)
  • Emulacja: Tak
  • Inne obsługiwane: brak
  • Standardowa dystrybucja: po Windows XP
  • Data wydania: 6 sierpnia 2004 r.

Xbox

W Xbox Microsoftu , chociaż procesor nie ma bitu NX, nowsze wersje XDK ustawiają limit segmentu kodu na początek sekcji .data jądra (w normalnych okolicznościach żaden kod nie powinien znajdować się po tym punkcie). Począwszy od wersji 51xx zmiana ta została również zaimplementowana w jądrze nowych Xboxów. To złamało techniki, które stare exploity wykorzystywały do ​​stania się TSR . Jednak szybko wydano nowe wersje obsługujące tę nową wersję, ponieważ podstawowy exploit nie został naruszony.

Ograniczenia

Tam, gdzie kod jest pisany i wykonywany w czasie wykonywania — wybitnym przykładem jest kompilator JIT — kompilator może potencjalnie zostać wykorzystany do wygenerowania kodu wykorzystującego lukę (np. przy użyciu JIT Spray ), który został oznaczony do wykonania i dlatego nie zostanie uwięziony.

Programowanie zorientowane na zwrot może pozwolić atakującemu na wykonanie dowolnego kodu, nawet jeśli wymuszana jest ochrona przestrzeni wykonywalnej.

Zobacz też

Bibliografia