Teo De Raad piani per rafforzare il meccanismo di protezione della memoria W^X (Write XOR Execute). Il senso del meccanismo è che le pagine di memoria del processo non possono essere accessibili sia in scrittura che in esecuzione contemporaneamente. 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 che l'esecuzione è stata vietata. Il meccanismo W^X aiuta a proteggere le applicazioni nello spazio utente da attacchi tipici, eseguiti attraverso il buffer overflow, inclusi gli overflow dello stack ed è attivo in OpenBSD. .
Sin dall'inizio dei lavori su W^X era chiaro che sarebbe stata una strada lunga, poiché esiste un numero significativo di applicazioni che utilizzano JIT. Le implementazioni JIT possono essere suddivise in tre categorie:
- Che alternano la memoria tra gli stati W e X, accettando il "costo" della chiamata di sistema. .
- Che creano alias tra una coppia di mappature W e X della stessa memoria.
- La variante più "sporca" – che richiede un modello di memoria W|X, che consente l'esecuzione simultanea di scrittura ed esecuzione.
Attualmente, ci sono significativamente meno programmi che utilizzano il terzo approccio e più che utilizzano il primo e il secondo. Tuttavia, poiché era necessario eseguire anche programmi con JIT W|X (principalmente, Chromium e Iridum), è stata aggiunta l'opzione di montaggio del file system "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 marcatore "wxneeded", e le stesse applicazioni venivano ulteriormente protette attraverso l'uso di meccanismi e per limitare l'elenco delle chiamate di sistema utilizzate e le parti del file system accessibili per l'applicazione di conseguenza.
Per complicare ulteriormente l'esploiting delle vulnerabilità in tali applicazioni, è stata proposta un'aggiunta al meccanismo , che controlla se la chiamata di sistema viene eseguita da una pagina di memoria accessibile in scrittura. Se la pagina è accessibile in scrittura, il processo viene terminato forzatamente. Così, l'attaccante non potrà utilizzare le chiamate di sistema e sarà costretto a cercare i gadget necessari nell'implementazione JIT o addirittura a svolgere un lavoro più difficile per scoprire i ganci delle chiamate di sistema direttamente all'interno .
I processi di Chrome/Iridium sono già abbastanza protetti grazie a pledge e unveil, ma impedire l'uso di, ad esempio, una chiamata di sistema write(2) offre chiaramente alcuni vantaggi, poiché crea ulteriori difficoltà per l'attaccante. Tuttavia, difficoltà possono sorgere anche se l'implementazione JIT utilizza chiamate di sistema native da memoria W|X. Tuttavia, ci sono motivi per sperare che non ci si debba confrontare con ciò, 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 testarle.
Una particolare menzione da parte di Theo è andata alle notizie correlate sull'introduzione in Chrome/Iridium della modalità . Dal suo punto di vista, ciò è accettabile per alcuni modelli d'uso, ma probabilmente non per tutti, poiché in questa modalità si prevede un aumento del carico sulla CPU. Al momento Chrome funzionerà principalmente se si disabilita «wxallowed» per /usr/local, sebbene ci possano essere problemi con alcune estensioni (si fa l'esempio di ghostery). In ogni caso, Theo spera che il funzionamento completo nella modalità JITless venga portato a uno stato completamente operativo nel prossimo futuro.
Fonte: opennet.ru
