Teo De Raad planuri privind întărirea mecanismului de protecție a memoriei W^X (Write XOR Execute). Esența mecanismului este că paginile de memorie ale procesului nu pot fi accesate simultan pentru scriere și execuție. Astfel, codul poate fi executat doar după interdicția scrierii, iar scrierea în pagina de memorie este posibilă doar după interdicția execuției. Mecanismul W^X ajută la protejarea aplicațiilor în spațiul utilizatorului împotriva atacurilor tipice realizate prin overflow de buffer, inclusiv împotriva overflow-urilor de stivă și este activ în OpenBSD. .
De la începutul lucrărilor la W^X a fost clar că este un drum lung, deoarece există un număr semnificativ de aplicații care utilizează JIT. Implementările JIT pot fi împărțite în trei categorii:
- Comutând memoria între stările W și X, acceptând „costul” apelului de sistem. .
- Creând aliasuri între pereche de hărți W și X ale aceleași memorii.
- Cea mai „murdară” variantă – cerând un model de memorie W|X, care permite implementarea simultană a scrierii și execuției.
În prezent, numărul de programe care utilizează a treia variantă a scăzut semnificativ și mai multe folosesc prima și a doua. Cu toate acestea, deoarece a fost necesar să se ruleze și programele cu JIT W|X (în principal, Chromium și Iridum), a fost adăugată opțiunea 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 markerul „wxneeded” iar aplicațiile în sine sunt protejate suplimentar utilizând mecanisme. și pentru restricționarea listei apelurilor de sistem utilizate și a părților sistemului de fișiere disponibile aplicației în consecință.
Pentru a complica și mai mult exploatarea vulnerabilităților în astfel de aplicații, a fost propus un supliment al mecanismului , care verifică dacă apelul de sistem este efectuat dintr-o pagină de memorie accesibilă pentru scriere. Dacă pagina este accesibilă pentru scriere, procesul este terminat forțat. Astfel, atacatorul nu va putea folosi apelurile de sistem și va fi nevoit să încerce să găsească gadgeturi necesare în implementarea JIT sau chiar să execute o muncă mai dificilă pentru a descoperi stub-uri ale apelurilor de sistem direct în interiorul .
Procesele Chrome/Iridium sunt deja protejate destul de eficient prin intermediul pledge și unveil, însă restricționarea accesului la apeluri sistemice precum write(2) are avantajele sale, întrucât creează dificultăți suplimentare pentru atacatori. Totuși, aceste dificultăți pot apărea și în cazul în care implementarea JIT utilizează apeluri sistemice native din memoria W|X. Cu toate acestea, există motive să credem că nu ne vom confrunta cu așa ceva, deoarece ABI-ul a fost modificat de mai multe ori, dar nimeni nu a raportat vreodată probleme.
Modificările sunt deja disponibile în instantanee regulate din ramura OpenBSD-Curent, toți cei interesați sunt invitați să participe la testare.
Un comentariu aparte din partea lui Theo merită știrile legate de introducerea în Chrome/Iridium a modului . Din perspectiva sa, acesta este acceptabil pentru anumite modele de utilizare, totuși, probabil nu pentru toate, deoarece în acest mod sarcina pe procesor va crește evident. În prezent, Chrome va funcționa în principal dacă dezactivezi „wxallowed” pentru /usr/local, deși este posibil să apară probleme cu unele extensii (de exemplu, ghostery). Oricum, Theo speră că funcționarea completă în modul JITless va fi adusă la o stare complet funcțională în curând.
Sursa: opennet.ro
