Theo De Raadt načrtuje okrepitev zaščitnega mehanizma pomnilnika W^X (Write XOR Execute). Bistvo mehanizma je, da do strani pomnilnika procesa ni mogoče istočasno dostopati za pisanje in izvajanje. Tako se koda lahko izvede šele, ko je pisanje onemogočeno, pisanje na pomnilniško stran pa je možno šele, ko je izvajanje onemogočeno. Mehanizem W^X pomaga zaščititi aplikacije uporabniškega prostora pred običajnimi napadi prekoračitve medpomnilnika, vključno s prekoračitvijo sklada, in je aktiven v OpenBSD .
Od začetka dela na W^X je bilo jasno, da je to dolga pot, saj je veliko aplikacij uporabljalo JIT. Izvedbe JIT lahko razdelimo v tri kategorije:
- Preklapljanje pomnilnika med stanjema W in X, sprejemanje "cene" sistemskega klica .
- Ustvarjanje vzdevkov med parom W in X preslikav istega pomnilnika.
- Najbolj “umazana” možnost zahteva pomnilniški model W|X, ki omogoča hkratno snemanje in izvajanje.
Trenutno je bistveno manj programov, ki uporabljajo tretjo možnost, več pa prvo in drugo. Ker pa je bilo potrebno zagnati programe z W|X JIT (predvsem Chromium in Iridum), je bila dodana možnost namestitve datotečnega sistema "wxallowed", ki je omogočila istočasno uporabo pomnilnika za pisanje in izvajanje, v primeru, da je izvršljivi ELF datoteka je označena z oznako “wxneeded”, same aplikacije pa smo dodatno zaščitili z mehanizmi и za omejitev seznama uporabljenih sistemskih klicev oziroma delov datotečnega sistema, ki so na voljo aplikaciji.
Za nadaljnje zapletanje izkoriščanja ranljivosti v takih aplikacijah je predlagan dodatek k mehanizmu , ki preveri, ali se sistemski klic izvaja s strani zapisljivega pomnilnika. Če je stran zapisljiva, se postopek prisilno prekine. Na ta način napadalec ne bo mogel izkoristiti sistemskih klicev in bo prisiljen poskušati poiskati potrebne pripomočke v izvedbi JIT ali celo opraviti težje delo odkrivanja škrbin sistemskih klicev neposredno znotraj .
Procesi Chrome/Iridium so že precej zanesljivo zaščiteni s pledge in unveil, vendar ima odstranitev možnosti uporabe na primer sistemskega klica write(2) očitno nekaj prednosti, saj napadalcu povzroča dodatne težave. Vendar pa lahko nastanejo tudi težave, če implementacija JIT uporablja izvorne sistemske klice iz pomnilnika W|X. Vendar obstaja razlog za upanje, da temu ne bo tako, saj je bil ABI že večkrat spremenjen, vendar še nihče ni poročal o težavah.
Spremembe so že na voljo v rednih posnetkih veje OpenBSD-Current, vsi zainteresirani vabljeni k testiranju.
Povezane novice o pojavu načina v Chromu/Iridiumu si zaslužijo ločen komentar Thea . Z njegovega vidika je to sprejemljivo za nekatere modele uporabe, verjetno pa ne za vse, saj bo ta način očitno povečal obremenitev procesorja. Trenutno bo Chrome večinoma deloval, če onemogočite »wxallowed« za /usr/local, čeprav lahko pride do težav z nekaterimi razširitvami (na primer ghostery). Tako ali drugače Theo upa, da bo polnopravno delo v načinu JITless v bližnji prihodnosti privedeno v popolnoma operativno stanje.
Vir: opennet.ru