W^X

W^X („napisz xor wykonaj”, wymawiane W xor X ) to funkcja bezpieczeństwa w systemach operacyjnych i maszynach wirtualnych . Jest to pamięci , zgodnie z którą każda strona w przestrzeni adresowej procesu lub jądra może być zapisywalna lub wykonywalna , ale nie oba. Bez takiej ochrony program może zapisywać (jako dane „W”) instrukcje procesora w obszarze pamięci przeznaczonym na dane, a następnie uruchamiać (jako plik wykonywalny „X” lub odczyt i wykonanie „RX”) te instrukcje. Może to być niebezpieczne, jeśli autor pamięci jest złośliwy. W^X to terminologia podobna do systemu Unix, określająca ścisłe użycie ogólnej koncepcji ochrony przestrzeni wykonywalnej , kontrolowanej przez wywołanie systemowe mprotect .

W^X jest stosunkowo prosty w przypadku procesorów obsługujących szczegółowe uprawnienia do stron, takich jak SPARC i SPARC64 firmy Sun , AMD64 firmy AMD , PA-RISC firmy Hewlett-Packard , Alpha firmy HP (pierwotnie Digital Equipment Corporation ) , i ARM .

Termin W^X został również zastosowany do uprawnień do zapisu/wykonania systemu plików w celu złagodzenia luk w zabezpieczeniach zapisu plików (jak w pamięci) i uporczywości atakującego. Egzekwowanie ograniczeń uprawnień do plików może również wypełnić luki w wymuszaniu W^X spowodowane przez pliki mapowane w pamięci. Całkowity zakaz używania dowolnego kodu natywnego może również złagodzić luki w jądrze i procesorze, które nie zostały ujawnione przez istniejący kod na komputerze. Mniej inwazyjnym podejściem jest zablokowanie pliku na czas mapowania do pamięci wykonywalnej, co wystarczy, aby zapobiec obejściu pokontrolnemu.

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 jest niedozwolone i dane są zlokalizowane, a poniżej którego jest dozwolone i umieszczane są strony wykonywalne. Ten schemat był używany w Exec Shield .

konsolidatora są zwykle wymagane w celu oddzielenia danych od kodu (takich jak trampoliny , które są potrzebne do funkcji środowiska uruchomieniowego konsolidatora i biblioteki ). Przełącznik umożliwiający miksowanie jest zwykle nazywany execstack w systemach typu Unix

W^X może również stanowić niewielki problem w przypadku kompilacji just-in-time , która obejmuje interpreter generujący kod maszynowy w locie, a następnie uruchamiający go. Proste rozwiązanie używane przez większość, w tym Firefox , polega na uczynieniu strony wykonywalną po tym, jak interpreter skończy pisać kod maszynowy, używając VirtualProtect w systemie Windows lub mprotect w systemach operacyjnych typu Unix. 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 zezwolenie na wykonanie strony, która kiedykolwiek była zapisywalna, mija się z celem W^X (istnieje polityka SELinux kontrolująca takie operacje o nazwie allow_execmod ) i że losowość układu przestrzeni adresowej umożliwiłoby 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ą przydzielone dwóm oddzielnym procesom, a komunikacja między procesami byłaby droższa niż wywoływanie 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ę o nazwie DEP ( Data Execution Prevention ) w systemie Windows XP. Podobne funkcje są dostępne dla innych systemów operacyjnych, w tym PaX i Exec Shield dla Linuksa oraz implementacja PaX w NetBSD . W Red Hat Enterprise Linux (i automatycznie CentOS ) w wersji 5 lub Linux Kernel 2.6.18-8, SELinux otrzymał allow_execmem , allow_execheap i allow_execmod zasady, które zapewniają W^X, gdy są wyłączone.

Chociaż W^X (lub DEP) przez większość swojego istnienia chronił tylko programy użytkownika, w 2012 roku Microsoft rozszerzył go na jądro systemu Windows na architekturach x86 i ARM. Pod koniec 2014 i na początku 2015 roku 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 AMD64 NetBSD i częściowo w jądrze i386.

Komputery z systemem macOS działające na krzemowych procesorach Apple wymuszają W^X dla wszystkich programów. Komputery Mac z procesorami Intel egzekwują te zasady tylko w przypadku programów korzystających z trybu Hardened Runtime systemu operacyjnego.

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

Począwszy od platformy .NET 6,0 w 2021 r., platforma .NET używa teraz W^X.

Linki zewnętrzne