Theo De Raadt planeja reforçar el mecanisme de protecció de memòria W^X (Write XOR Execute). L'essència del mecanisme és que no es pot accedir simultàniament a les pàgines de memòria del procés per escriure i executar-les. Per tant, el codi només es pot executar després que l'escriptura estigui inhabilitada, i l'escriptura en una pàgina de memòria només és possible després que l'execució estigui inhabilitada. El mecanisme W^X ajuda a protegir les aplicacions de l'espai d'usuari d'atacs comuns de desbordament de memòria intermèdia, inclosos els desbordaments de pila, i està actiu a OpenBSD .
Des de l'inici del treball a W^X, va quedar clar que aquest era un camí llarg, ja que hi havia un nombre important d'aplicacions que utilitzaven JIT. Les implementacions JIT es poden dividir en tres categories:
- Canviar la memòria entre els estats W i X, acceptant el "cost" de la trucada al sistema .
- Creació d'àlies entre un parell de mapes W i X de la mateixa memòria.
- L'opció més "bruta" requereix un model de memòria W|X que permeti l'enregistrament i l'execució simultània.
Actualment, hi ha molt menys programes que utilitzen la tercera opció i més que utilitzen la primera i la segona. No obstant això, com que era necessari executar programes amb W|X JIT (principalment Chromium i Iridum), es va afegir una opció de muntatge del sistema de fitxers "wxallowed", que permetia utilitzar la memòria simultàniament tant per a l'escriptura com per a l'execució, per si l'executable ELF el fitxer està marcat amb el marcador "wxneeded" i les aplicacions es van protegir addicionalment mitjançant mecanismes и per limitar la llista de trucades al sistema utilitzades i parts del sistema de fitxers disponibles per a l'aplicació, respectivament.
Per complicar encara més l'explotació de vulnerabilitats en aquestes aplicacions, es proposa un afegit al mecanisme , que comprova si la trucada al sistema s'està executant des d'una pàgina de memòria que es pot escriure. Si la pàgina es pot escriure, el procés es veu obligat a finalitzar. D'aquesta manera, un atacant no podrà explotar les trucades del sistema i es veurà obligat a intentar trobar els gadgets necessaris a la implementació de JIT o fins i tot fer el treball més difícil de detectar els talons de trucades del sistema directament dins. .
Els processos de Chrome/Iridium ja estan protegits de manera bastant fiable mitjançant promesa i revelació, però eliminar la possibilitat d'utilitzar, per exemple, la crida al sistema write(2) òbviament té algun avantatge, ja que crea dificultats addicionals per a l'atacant. Tanmateix, també poden sorgir dificultats si la implementació JIT utilitza trucades natives del sistema des de la memòria W|X. Tanmateix, hi ha motius per esperar que això no sigui així, ja que l'ABI s'ha modificat diverses vegades, però ningú no ha informat mai de problemes.
Els canvis ja estan disponibles en instantànies regulars de la branca OpenBSD-Actual, tots els interessats estan convidats a provar.
Les notícies relacionades sobre l'aparició del mode a Chrome/Iridium mereixen un comentari a part de Theo . Des del seu punt de vista, això és acceptable per a alguns models d'ús, però probablement no per a tots, ja que aquest mode òbviament augmentarà la càrrega del processador. Actualment, Chrome funcionarà principalment si desactiveu "wxallowed" per a /usr/local, tot i que hi pot haver problemes amb algunes extensions (ghostery n'és un exemple). D'una manera o d'una altra, Theo espera que el treball complet en mode JITless es porti a un estat totalment operatiu en un futur proper.
Font: opennet.ru