Theo De Raadt prevede di rafforzare il meccanismo di protezione della memoria W^X (Write XOR Execute). L'essenza del meccanismo è che non è possibile accedere simultaneamente alle pagine della memoria del processo per la scrittura e l'esecuzione. Pertanto, il codice può essere eseguito solo dopo che la scrittura è disabilitata e la scrittura su una pagina di memoria è possibile solo dopo che l'esecuzione è disabilitata. Il meccanismo W^X aiuta a proteggere le applicazioni dello spazio utente dai comuni attacchi di buffer overflow, inclusi gli stack overflow, ed è attivo in OpenBSD .
Fin dall'inizio del lavoro su W^X, era chiaro che si trattava di una strada lunga, poiché esisteva un numero significativo di applicazioni che utilizzavano JIT. Le implementazioni JIT possono essere suddivise in tre categorie:
- Commutare la memoria tra gli stati W e X, accettando il "costo" della chiamata di sistema .
- Creazione di alias tra una coppia di mappature W e X della stessa memoria.
- L'opzione più “sporca” richiede un modello di memoria W|X che consenta la registrazione e l'esecuzione simultanee.
Attualmente, ci sono molti meno programmi che utilizzano la terza opzione e molti che utilizzano la prima e la seconda. Tuttavia, poiché era necessario eseguire programmi con W|X JIT (principalmente Chromium e Iridum), è stata aggiunta un'opzione di montaggio del filesystem "wxallowed", che consentiva di utilizzare la memoria contemporaneamente sia per la scrittura che per l'esecuzione, nel caso in cui l'eseguibile ELF il file è contrassegnato con il contrassegno "wxneeded" e le applicazioni stesse sono state ulteriormente protette utilizzando meccanismi и per limitare rispettivamente l'elenco delle chiamate di sistema utilizzate e le parti del file system disponibili per l'applicazione.
Per complicare ulteriormente lo sfruttamento delle vulnerabilità in tali applicazioni, viene proposta un'aggiunta al meccanismo , che controlla se la chiamata di sistema viene eseguita da una pagina di memoria scrivibile. Se la pagina è scrivibile, il processo viene forzato a terminare. In questo modo, un utente malintenzionato non sarà in grado di sfruttare le chiamate di sistema e sarà costretto a cercare i gadget necessari nell'implementazione JIT, o addirittura a svolgere il lavoro più difficile di rilevare gli stub delle chiamate di sistema direttamente all'interno .
I processi Chrome/Iridium sono già protetti in modo abbastanza affidabile utilizzando pledge e unveil, ma rimuovere la possibilità di utilizzare, ad esempio, la chiamata di sistema write(2) ha ovviamente qualche vantaggio, poiché crea ulteriori difficoltà per l'aggressore. Tuttavia, possono sorgere difficoltà anche se l'implementazione JIT utilizza chiamate di sistema native dalla memoria W|X. C'è però motivo di sperare che così non sia, visto che l'ABI è stata modificata più volte, ma nessuno ha mai segnalato problemi.
Le modifiche sono già disponibili negli snapshot regolari del ramo OpenBSD-Current, tutti gli interessati sono invitati a testarli.
Le notizie correlate all'aspetto della modalità Chrome/Iridium meritano un commento a parte da parte di Theo . Dal suo punto di vista, questo è accettabile per alcuni modelli di utilizzo, ma probabilmente non per tutti, poiché questa modalità ovviamente aumenterà il carico sul processore. Attualmente, Chrome funzionerà principalmente se disabiliti "wxallowed" per /usr/local, anche se potrebbero esserci problemi con alcune estensioni (ghostery è un esempio). In un modo o nell'altro, Theo spera che il lavoro a tutti gli effetti in modalità JITless venga portato a uno stato pienamente operativo nel prossimo futuro.
Fonte: opennet.ru