bazad/x18-leakCVE-2018-4185: divulgazione di puntatori del kernel in iOS 11.2-11.2.6 introdotta dalla mitigazione Meltdown di Apple.
===================================================================================================
iOS 11.2 ha introdotto una fuga di informazioni dal kernel che poteva essere utilizzata per determinare lo slide del kASLR. Il problema era il risultato di una funzionalità appena aggiunta, __ARM_KERNEL_PROTECT__, che faceva sì che l'indirizzo della funzione del kernel Lel0_synchronous_vector_64_long comparisse nel registro x18 quando si ottenevano i valori dei registri di un thread tramite thread_get_state. Il problema è stato scoperto quando i puntatori al kernel hanno iniziato a comparire nei log di crash delle applicazioni iOS.
In iOS 11.2, Apple ha introdotto una funzionalità su arm64 chiamata __ARM_KERNEL_PROTECT__. Secondo un commento in osfmk/arm64/proc_reg.h:
__ARM_KERNEL_PROTECT__ is a feature intended to guard against potential
architectural or microarchitectural vulnerabilities that could allow cores to
read/access EL1-only mappings while in EL0 mode. This is achieved by
removing as many mappings as possible when the core transitions to EL0 mode
from EL1 mode, and restoring those mappings when the core transitions to EL1
mode from EL0 mode.
In altre parole, quando si passa da EL1 (modalità kernel) a EL0 (modalità utente), vengono rimosse quante più mappature del kernel possibile. Questo dovrebbe limitare la possibile superficie di attacco contro le mappature della memoria del kernel quando si sfruttano vulnerabilità microarchitetturali come Spectre o Meltdown.
Se si esamina il diff tra le versioni di XNU 4570.20.62 e 4570.31.3, si vedranno comparire numerosi nuovi riferimenti al registro x18 nel file osfmk/arm64/locore.s in relazione a __ARM_KERNEL_PROTECT__. In particolare, si vedrà che il vettore di eccezione Lel0_synchronous_vector_64, ovvero il vettore di eccezione invocato su una chiamata di sistema (istruzione svc #0), ora appare così:
.text
.align 7
Lel0_synchronous_vector_64:
MAP_KERNEL
BRANCH_TO_KVA_VECTOR Lel0_synchronous_vector_64_long, 8
La macro BRANCH_TO_KVA_VECTOR è definita come:
.macro BRANCH_TO_KVA_VECTOR
#if __ARM_KERNEL_PROTECT__
/*
* Find the kernelcache table for the exception vectors by accessing
* the per-CPU data.
*/
mrs x18, TPIDR_EL1
ldr x18, [x18, ACT_CPUDATAP]
ldr x18, [x18, CPU_EXC_VECTORS]
/*
* Get the handler for this exception and jump to it.
*/
ldr x18, [x18, #($1 << 3)]
br x18
#else
b $0
#endif /* __ARM_KERNEL_PROTECT__ */
.endmacro
Questa macro esegue un salto indiretto alla vera implementazione del vettore di eccezione, Lel0_synchronous_vector_64_long, caricando un puntatore a tale funzione nel registro x18. Si noti, tuttavia, che questa sovrascrittura di x18 avviene prima che i registri dello spazio utente vengano salvati dalla funzione fleh_dispatch64, chiamata da Lel0_synchronous_vector_64_long. Ciò significa che quando i registri utente vengono salvati, x18 conterrà in realtà un puntatore a Lel0_synchronous_vector_64_long anziché il valore originale proveniente dallo spazio utente.
Anche se x18 viene azzerato al ritorno dall'eccezione, memorizzare un puntatore al kernel nello stato dei registri utente è problematico perché thread_get_state può essere usata per copiare lo stato dei registri utente salvato di nuovo nello spazio utente, incluso il valore del registro x18. Tutto ciò che un thread deve fare per ottenere l'indirizzo della funzione Lel0_synchronous_vector_64_long è chiamare thread_get_state su se stesso e osservare il valore riportato di x18. Questo rende banale determinare lo slide del kASLR sottraendo dal valore di x18 così ottenuto l'indirizzo statico di Lel0_synchronous_vector_64_long.
Come accennato sopra, lo sfruttamento è banale: basta chiamare la funzione thread_get_state, guardare il valore del registro x18 e sottrarre da esso l'indirizzo statico della funzione del kernel Lel0_synchronous_vector_64_long.
Ho scoperto questo problema il 26 febbraio 2018, dopo aver notato un puntatore al kernel nel registro x18 di un log di crash di un'applicazione iOS. Un rapido controllo ha mostrato che lo stesso valore compariva nel registro x18 di ogni log di crash sul dispositivo, il che suggeriva una grave fuga di informazioni.
Ho quindi cercato di determinare cosa stesse esattamente succedendo con il registro x18 attraverso la sperimentazione. Ho impostato un breakpoint in un'app iOS vuota e ho usato lldb per leggere il valore del registro x18, confermando che la fuga non era limitata alle applicazioni in crash. Successivamente ho provato a leggere il valore di x18 usando assembly inline e ho scoperto che il valore ottenuto non corrispondeva a quello mostrato dal debugger usando un comando come reg read x18. Questo suggeriva che forse la fuga fosse in realtà in thread_get_state e che il registro x18 non contenesse davvero un puntatore al kernel mentre la CPU era in esecuzione nello spazio utente. Una rapida prova di concetto che leggeva il valore di x18 usando thread_get_state ha confermato che questa funzione era effettivamente la fonte della fuga.
Ho segnalato il problema ad Apple il 26 febbraio 2018, lo stesso giorno in cui l'ho scoperto.
Di Brandon Azad