Theo De Raadt intenționează să consolideze mecanismul de protecție a memoriei W^X (Write XOR Execute). Esența mecanismului este că paginile de memorie de proces nu pot fi accesate simultan pentru scriere și execuție. Astfel, codul poate fi executat numai după ce scrierea este dezactivată, iar scrierea pe o pagină de memorie este posibilă numai după ce execuția este dezactivată. Mecanismul W^X ajută la protejarea aplicațiilor din spațiul utilizatorului de atacurile comune de depășire a memoriei tampon, inclusiv depășirea stivei și este activ în OpenBSD .
De la începutul lucrărilor pe W^X, a fost clar că acesta a fost un drum lung, deoarece exista un număr semnificativ de aplicații care foloseau JIT. Implementările JIT pot fi împărțite în trei categorii:
- Comutarea memoriei între stările W și X, acceptând „costul” apelului de sistem .
- Crearea de aliasuri între o pereche de mapări W și X ale aceleiași memorie.
- Cea mai „murdară” opțiune necesită un model de memorie W|X care să permită înregistrarea și execuția simultană.
În prezent, există semnificativ mai puține programe care folosesc a treia opțiune și mai multe care folosesc prima și a doua. Cu toate acestea, deoarece a fost necesar să rulați programe cu W|X JIT (în principal Chromium și Iridum), a fost adăugată o opțiune de montare a sistemului de fișiere „wxallowed”, care permitea utilizarea memoriei simultan pentru scriere și execuție, în cazul în care fișierul executabil ELF este marcat cu marcatorul „wxneeded”, iar aplicațiile în sine au fost protejate suplimentar folosind mecanisme и pentru a limita lista apelurilor de sistem utilizate și, respectiv, părțile sistemului de fișiere disponibile pentru aplicație.
Pentru a complica și mai mult exploatarea vulnerabilităților în astfel de aplicații, se propune o completare la mecanism , care verifică dacă apelul de sistem este executat dintr-o pagină de memorie care poate fi scrisă. Dacă pagina poate fi scrisă, procesul este forțat să se încheie. În acest fel, un atacator nu va putea exploata apelurile de sistem și va fi forțat să încerce să găsească gadget-urile necesare în implementarea JIT sau chiar să facă munca mai dificilă de a detecta stub-urile de apel de sistem direct în interior. .
Procesele Chrome/Iridium sunt deja protejate destul de fiabil folosind promisiunea și dezvăluirea, dar eliminarea capacității de a utiliza, de exemplu, apelul de sistem write(2) are, evident, un oarecare avantaj, deoarece creează dificultăți suplimentare atacatorului. Cu toate acestea, pot apărea dificultăți și dacă implementarea JIT utilizează apeluri de sistem native din memoria W|X. Cu toate acestea, există motive să sperăm că nu va fi așa, deoarece ABI-ul a fost schimbat de mai multe ori, dar nimeni nu a raportat vreodată probleme.
Modificările sunt deja disponibile în instantanee obișnuite ale sucursalei OpenBSD-Current, toți cei interesați sunt invitați să testeze.
Știrile similare despre apariția modului în Chrome/Iridium merită un comentariu separat de la Theo . Din punctul său de vedere, acest lucru este acceptabil pentru unele modele de utilizare, dar probabil nu pentru toate, deoarece acest mod va crește în mod evident sarcina pe procesor. În prezent, Chrome va funcționa în mare parte dacă dezactivați „wxallowed” pentru /usr/local, deși pot apărea probleme cu unele extensii (ghostery este un exemplu). Într-un fel sau altul, Theo speră că munca cu drepturi depline în modul JITless va fi adusă la o stare complet operațională în viitorul apropiat.
Sursa: opennet.ru