ARM-XN, DEP, ROP e ASLR?
TH: Perché il bit ARM-XN, conosciuto anche come XN-bit o XD-bit, non riesce a evitare attacchi del genere?
Charlie: Prima del Data Execution Prevention (DEP) i sovraccarichi del buffer (buffer overflow) erano sufficienti per eseguire codice a livello utente, o shellcode. La DEP impedisce che questo accada, come se il processore sapesse che i dati inseriti non devono contenere codice da eseguire. Per aggirare questo limite gli exploit usano una cosa chiamata ROP (Return Oriented Programming). Questa soluzione permette di saltare dal codice al processo vero e proprio, in questo caso MobileSafari e relative librerie. Si riutilizzano piccole parti del codice attive del processo, e così l'exploit riesce a compiere l'azione necessaria per ottenere il risultato.
TH: Cerchiamo di comprendere meglio. iOS ha una forma di DEP, che impedisce l'inserimento di codice arbitrario da parte dell'utente o di applicazioni scritte ad hoc. Ma si può aggirare questo limite usando frammenti di codice autorizzato. Come una lettera di riscatto ottenuta con i ritagli di giornale?
Charlie: Sì, l'uso della protezione DEP in iOS è molto buona. L'analogia della lettera è perfetta: prendi frammenti di codice esistente e li incolli in modo da ottenere quello che vuoi, e che non era nei programmi dello sviluppatore originale.
Lettera di riscatto... C'è un'applicazione anche per questo!
TH: Cosa ci dici di tecnologie come l'ASLR o la stack randomization? Sarebbe una soluzione?
Charlie: Sì, in generale la tecnica ASLR riesce a bloccare il codice riciclato, perché rende causale (randomizza) la collocazione del codice necessario per portare a termine l'exploit. Se l'exploit non riesce a trovare il codice di cui ha bisogno, non può effettuare un attacco ROP. L'iPhone però non usa tecnologia ASLR: un eventuale aggressore può conoscere tutti gli indirizzi che gli servono, se conosce la versione del firmware installata.