Binari gadgetless resistenti alla ROP

Question

Binari gadgetless resistenti alla ROP

#1 da (3 voti)

5

G-Free: sconfiggere la programmazione orientata al rendimento tramite i binari senza gadget

Questo documento descrive quella che sembra una tecnica davvero interessante per prevenire gli attacchi ROP se la fonte è disponibile. Usano un preprocessore di assemblaggio tra gcc e l'assemblatore per rimuovere o proteggere tutti i possibili rami liberi (ritorni e salti indiretti). Sostengono di avere un impatto sulla velocità / prestazioni del 3% (1% in media).

Modificano le istruzioni o aggiungono no-op per modificare l'allineamento in modo da eliminare le istruzioni di diramazione non intenzionali / non allineate. Per proteggere i ritorni e i salti legittimi, crittografano l'indirizzo di ritorno con una chiave di runtime casuale nel prologo della funzione e lo decodificano da XOR appena prima del ritorno. Questo dovrebbe impedire l'esecuzione dell'output di ritorno a meno che il punto di ingresso non fosse all'inizio della funzione stessa.

La mia domanda è: come verrà restituita la crittografia dell'indirizzo, impedendo l'utilizzo dei gadget ROP? La chiave / cookie è memorizzata nello stack appena sopra l'indirizzo di ritorno, quindi cosa deve impedire all'utente malintenzionato di modificare la catena di gadget nello stack per includere anche una chiave 0x00000000 dopo ogni indirizzo di ritorno?

Il documento sembra avere 73 citazioni e nessuno ha menzionato nulla di simile per quanto posso vedere quindi mi manca qualcosa. Qualcuno può far luce su come funziona il codice di protezione per salti e ritorni legittimi?

(So che questa è una lunga domanda che richiede la lettura di un lungo documento, ma spero che almeno chi legge questo trovi il giornale così bello come lo feci)

Aggiorna

Questa è apparentemente la stessa (o molto simile) tecnica utilizzata in StackGuard e ProPolice. Qualcuno può dirmi come vanno contro le vulnerabilità di divulgazione della memoria? Non riesco a capire di sicuro. Quello che trovo o li cita di passaggio o si limita a trombare le loro virtù.

exploit

posta staticd 10.12.2013 - 06:16

fonte

1 risposta

Leggi altre domande sui tag exploit

Codifica di un indirizzo che contiene un byte nullo in un payload Problemi di sicurezza dell'API REST Tokenless

score 3 · Answer 1

La crittografia dell'indirizzo di ritorno impedisce l'utilizzo dei gadget ROP perché l'utente malintenzionato non sarà in grado di prevedere il valore della chiave, quindi l'utente malintenzionato non saprà cosa scrivere sullo stack per causare l'istruzione di ritorno alla fine di un gadget per trasferire il controllo al prossimo gadget.

Ricorda come funzionano gli attacchi ROP. L'attacco comporta l'esecuzione di una sequenza di gadget ROP. L'attaccante deve organizzare la memoria in modo che questi gadget vengano eseguiti nella sequenza desiderata. In un attacco ROP, l'attaccante esegue questa operazione sovrascrivendo lo stack per contenere una serie di frame di stack falsi, in cui ogni frame dello stack contiene qualsiasi dato dello stack sarà necessario / previsto da un singolo gadget. Ogni gadget ROP termina con un'istruzione RET (return), quindi il frame dello stack falso corrispondente contiene un indirizzo di ritorno salvato che verrà utilizzato dall'istruzione RET: quando si esegue il gadget, quando si arriva all'istruzione RET, l'istruzione RET fai uscire "l'indirizzo del mittente" nello stack e salta su di esso. Quindi, l'attaccante dispone il contenuto dello stack in modo che abbia un "indirizzo di ritorno" falso per ogni gadget e il falso "indirizzo di ritorno" ha un valore che è l'indirizzo della prima istruzione del prossimo gadget da eseguire.

In un attacco ROP standard, questo funziona, perché l'attaccante conosce l'indirizzo di ciascun gadget e può scrivere quegli indirizzi nello stack.

Con la crittografia dell'indirizzo di ritorno di G-Free, questo attacco non funziona più. L'attaccante non può memorizzare l'indirizzo del gadget nello stack; l'utente malintenzionato deve invece memorizzare un indirizzo di ritorno crittografato (ovvero la crittografia dell'indirizzo del prossimo gadget). Senza conoscere la chiave di crittografia, l'autore dell'attacco non saprà cosa scrivere.

Quindi, senza conoscere la chiave di crittografia, gli attacchi ROP non funzionano, perché l'attaccante non può concatenare i gadget insieme.

P.S. Sono d'accordo con te. G-Free è davvero fantastico. Vorrei avere un flag del compilatore che mi permetta di compilare un programma con G-Free; è una difesa molto interessante, con un impatto modesto sulle prestazioni.