W^X - W^X

W^X („zapisz xor wykonaj”, wymawiane W xor X ) to funkcja bezpieczeństwa w systemach operacyjnych i maszynach wirtualnych . Jest to pamięć polityka ochrony przy czym każda strona w procesie „s lub jądra ” s przestrzeń adresowa może być zapisywalny lub plik wykonywalny , ale nie jednocześnie. Bez takiej ochrony program może zapisywać (jako dane „W”) instrukcje procesora w obszarze pamięci przeznaczonym na dane, a następnie uruchamiać (jako wykonywalny „X” lub odczyt-wykonywać „RX”) te instrukcje. Może to być niebezpieczne, jeśli zapisujący pamięć jest złośliwy. W^X jest terminologią uniksopodobną do ścisłego użycia ogólnej koncepcji ochrony wykonywalnej przestrzeni , kontrolowanej przez mprotectwywołanie systemowe.

W ^ X jest stosunkowo prosta na procesorach które obsługują uprawnienia strona drobnoziarniste, takie jak Sun 's SPARC i SPARC64 AMD ' s AMD64 , Hewlett-Packard jest PA-RISC , HP (pierwotnie Digital Equipment Corporation 's) Alpha , i ARM .

W^X został również zastosowany do uprawnień do zapisu/wykonywania w systemie plików w celu złagodzenia luk w zapisie plików (jak w przypadku pamięci) i trwałości atakującego. Wymuszanie ograniczeń uprawnień do plików może również wypełnić luki w egzekwowaniu W^X spowodowane przez pliki mapowane w pamięci. Całkowite zakazanie korzystania z dowolnego kodu natywnego może również złagodzić luki w zabezpieczeniach jądra i procesora, które nie zostały ujawnione przez istniejący kod na komputerze.

Zgodność

Niektórym wczesnym procesorom Intel 64 brakowało bitu NX wymaganego dla W^X, ale pojawił się on w późniejszych układach. Na bardziej ograniczonych procesorach, takich jak Intel i386 , W^X wymaga użycia limitu segmentu kodu CS jako „ linii na piasku ”, punktu w przestrzeni adresowej, powyżej którego wykonanie nie jest dozwolone i znajdują się dane, a poniżej którego jest dozwolone i umieszczane są strony wykonywalne. Ten schemat został użyty w Exec Shield .

Linker zmiany są na ogół wymagane do oddzielnych danych z kodu (takie jak trampoliny , które są potrzebne do łącznika i bibliotek uruchomieniowych funkcji). Przełącznik umożliwiający miksowanie jest zwykle nazywany execstackw systemach uniksopodobnych

W^X może również stanowić drobny problem przy kompilacji just-in-time , która polega na tym, że interpreter generuje kod maszynowy w locie, a następnie go uruchamia. Proste rozwiązanie używane przez większość, w tym przez Firefox , polega po prostu na uczynieniu strony wykonywalną po tym, jak interpreter zakończy pisanie kodu maszynowego, używając VirtualProtectw systemie Windows lub mprotectuniksopodobnym. Drugie rozwiązanie polega na mapowaniu tego samego obszaru pamięci na dwie strony, jedną z RW, a drugą z RX. Nie ma prostego konsensusu co do tego, które rozwiązanie jest bezpieczniejsze: zwolennicy tego drugiego podejścia uważają, że umożliwienie wykonania strony, która kiedykolwiek była zapisywalna, jest sprzeczne z celem W^X (istnieje polityka SELinux do kontrolowania takich operacji o nazwie allow_execmod) i adres randomizacja układu przestrzeni zapewniłaby bezpieczne umieszczenie obu stron w tym samym procesie. Zwolennicy pierwszego podejścia uważają, że drugie podejście jest bezpieczne tylko wtedy, gdy dwie strony są przydzielane dwóm oddzielnym procesom, a komunikacja między procesami byłaby droższa niż wywołanie mprotect.

Historia

W^X został po raz pierwszy zaimplementowany w OpenBSD 3.3, wydanym w maju 2003 roku. W 2004 roku Microsoft wprowadził podobną funkcję zwaną DEP ( Data Execution Prevention ) w systemie Windows XP. Podobne funkcje są dostępne dla innych systemów operacyjnych, włączając w to łatki PaX i Exec Shield dla Linuksa oraz implementację PaX w NetBSD . W systemie Red Hat Enterprise Linux (i automatycznie CentOS ) w wersji 5 lub Linux Kernel 2.6.18-8, SELinux otrzymał allow_execmem, allow_execheapi allow_execmodpolityk, które zapewnią W ^ X, gdy jest wyłączona.

Chociaż W^X (lub DEP) przez większość swojego istnienia chronił tylko programy użytkownika, w 2012 r. Microsoft rozszerzył go na jądro Windows na architekturach x86 i ARM. Pod koniec 2014 i na początku 2015, W^X został dodany do jądra OpenBSD na architekturze AMD64. Na początku 2016 roku W^X został w pełni zaimplementowany w jądrze NetBSD AMD64 i częściowo w jądrze i386.

Począwszy od Firefoksa 46 w 2016 r., maszyna wirtualna Firefoksa dla JavaScript również implementuje zasady W^X.

Zobacz też

Bibliografia

  1. ^ "Wymuszaj ograniczenia execve() dla API > 28" .
  2. ^ „Wiadomości Kernel Zacka” .
  3. ^ "SARA nowy stos LSM" .
  4. ^ „Utwardzanie jądra Linuksa (seria 2.0.x)” .
  5. ^ "i386 W^X" . 17 kwietnia 2003 . Źródło 19 czerwca 2014 .
  6. ^ execstack(8)  –  Podręcznik administracji systemu Linux
  7. ^ a b "Kod W^X JIT włączony w Firefoksie" . Źródło 29 kwietnia 2016 .
  8. ^ „Wykorzystaj ulepszenia łagodzenia skutków w Win8” .
  9. ^ "Ochrona W^X dla jądra AMD64" .

Zewnętrzne linki