Theo De Raadt i piani per migliorare il meccanismo di protezione della memoria W^X (Write XOR Execute). Il principio del meccanismo è che le pagine di memoria di un processo non possono essere accessibili contemporaneamente in scrittura ed esecuzione. In questo modo, il codice può essere eseguito solo dopo che la scrittura è stata vietata, e la scrittura in una pagina di memoria è possibile solo dopo aver vietato l'esecuzione. Il meccanismo W^X aiuta a proteggere le applicazioni nello spazio utente da attacchi comuni, effettuati tramite overflow del buffer, inclusi gli overflow dello stack, ed è attivo in OpenBSD. .
Sin dall'inizio dei lavori su W^X era chiaro che sarebbe stata una lunga strada, poiché esiste un numero significativo di applicazioni che utilizzano JIT. Le implementazioni JIT possono essere suddivise in tre categorie:
- Spostano la memoria tra gli stati W e X, accettando il "costo" della chiamata di sistema .
- Creano alias tra una coppia di mapping W e X della stessa memoria.
- La variante più "sporca" — richiede un modello di memoria W|X, che consente l'esecuzione e la scrittura simultanee.
Attualmente ci sono significativamente meno programmi che utilizzano la terza opzione e più che utilizzano la prima e la seconda. Tuttavia, poiché era necessario eseguire programmi con W|X JIT (principalmente Chromium e Iridum), è stata aggiunta l'opzione di montaggio del file di sistema «wxallowed», che consentiva di utilizzare la memoria sia per la scrittura che per l'esecuzione, nel caso in cui il file ELF eseguibile fosse contrassegnato con il marker «wxneeded», e le applicazioni stesse fossero ulteriormente protette utilizzando meccanismi. e per limitare l'elenco delle chiamate di sistema utilizzate e delle parti del file system disponibili per l'applicazione rispettivamente.
Per rendere ulteriormente complessa l'esecuzione di vulnerabilità in tali applicazioni, è stato proposto un miglioramento del meccanismo. , che verifica se una chiamata di sistema viene eseguita da una pagina di memoria scrivibile. Se la pagina è accessibile in scrittura, il processo viene terminato forzatamente. In questo modo, un attaccante non sarà in grado di utilizzare le chiamate di sistema e sarà costretto a tentare di trovare i gadget necessari nell'implementazione JIT o persino a eseguire un lavoro più difficile di rilevamento dei segnaposto delle chiamate di sistema direttamente all'interno .
I processi Chrome/Iridium sono già abbastanza protetti attraverso pledge e unveil, ma privare la possibilità di utilizzare, ad esempio, la chiamata di sistema write(2), ha sicuramente un certo vantaggio, poiché crea ulteriori difficoltà per l'attaccante. Tuttavia, difficoltà potrebbero sorgere anche nel caso in cui l'implementazione JIT utilizzi chiamate di sistema native da memoria W|X. Tuttavia, ci sono ragioni per sperare che ciò non accadrà, poiché l'ABI è cambiato 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 testare.
Un commento separato da Theo merita le notizie correlate sull'introduzione della modalità in Chrome/Iridium. . Dal suo punto di vista, questo è accettabile per alcuni modelli d'uso, ma probabilmente non per tutti, poiché in questa modalità ovviamente aumenterà il carico sulla CPU. Attualmente, Chrome funzionerà principalmente se si disabilita «wxallowed» per /usr/local, anche se potrebbero sorgere problemi con alcune estensioni (come ad esempio Ghostery). In ogni caso, Theo spera che la funzionalità completa in modalità JITless venga portata a uno stato completamente operativo nel prossimo futuro.
Fonte: opennet.ru
