bazad/x18-leakCVE-2018-4185: divulgação de ponteiros do kernel do iOS 11.2-11.2.6 introduzida pela mitigação Meltdown da Apple.
O iOS 11.2 introduziu um vazamento de informações do kernel que poderia ser usado para determinar o deslocamento do kASLR. O problema foi resultado de uma funcionalidade recém-adicionada, __ARM_KERNEL_PROTECT__, que inadvertidamente fez com que o endereço da função do kernel Lel0_synchronous_vector_64_long aparecesse no registrador x18 ao obter os valores dos registradores de uma thread usando thread_get_state. O problema foi descoberto quando ponteiros do kernel começaram a aparecer nos logs de falha de aplicativos iOS.
No iOS 11.2, a Apple introduziu uma funcionalidade no arm64 chamada __ARM_KERNEL_PROTECT__. De acordo com um comentário em osfmk/arm64/proc_reg.h:
__ARM_KERNEL_PROTECT__ é uma funcionalidade destinada a proteger contra potenciais vulnerabilidades arquiteturais ou microarquiteturais que poderiam permitir que núcleos lessem/acessassem mapeamentos somente EL1 enquanto no modo EL0. Isso é alcançado removendo o máximo de mapeamentos possível quando o núcleo transita do modo EL1 para o modo EL0 e restaurando esses mapeamentos quando o núcleo transita do modo EL1 para o modo EL0.
Ou seja, ao fazer a transição de EL1 (modo kernel) para EL0 (modo usuário), o máximo de mapeamentos do kernel possível será removido. Isso deve limitar a superfície de ataque possível contra mapeamentos de memória do kernel ao explorar vulnerabilidades microarquiteturais como Spectre ou Meltdown.
Se você examinar a diferença entre as versões do XNU 4570.20.62 e 4570.31.3, encontrará várias novas referências ao registrador x18 aparecendo no arquivo osfmk/arm64/locore.s em relação a __ARM_KERNEL_PROTECT__. Em particular, você verá que o vetor de exceção Lel0_synchronous_vector_64, que é o vetor de exceção invocado em uma chamada de sistema (instrução svc #0), agora se parece com isso:
.text
.align 7
Lel0_synchronous_vector_64:
MAP_KERNEL
BRANCH_TO_KVA_VECTOR Lel0_synchronous_vector_64_long, 8
A macro BRANCH_TO_KVA_VECTOR é definida como:
.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
Esta macro realiza um desvio indireto para a implementação real do vetor de exceção, Lel0_synchronous_vector_64_long, carregando um ponteiro para essa função no registrador x18. Observe, no entanto, que essa sobrescrita de x18 ocorre antes que os registradores do espaço do usuário sejam salvos pela função fleh_dispatch64, que é chamada por Lel0_synchronous_vector_64_long. Isso significa que, quando os registradores do usuário são salvos, x18 será na verdade um ponteiro para Lel0_synchronous_vector_64_long em vez do valor original do espaço do usuário.
Mesmo que x18 seja limpo no retorno da exceção, armazenar um ponteiro do kernel no estado do registrador do usuário é problemático porque thread_get_state pode ser usado para copiar o estado salvo do registrador do usuário de volta para o espaço do usuário, incluindo o valor do registrador x18. Tudo o que uma thread precisa fazer para obter o endereço da função Lel0_synchronous_vector_64_long é chamar thread_get_state em si mesma e observar o valor reportado de x18. Isso torna trivial determinar o deslocamento do kASLR subtraindo o valor de x18 assim obtido pelo endereço estático de Lel0_synchronous_vector_64_long.
Como mencionado acima, a exploração é trivial: basta chamar a função thread_get_state, observar o valor do registrador x18 e subtrair dele o endereço estático da função do kernel Lel0_synchronous_vector_64_long.
Descobri esse problema em 26 de fevereiro de 2018, depois de notar um ponteiro do kernel no registrador x18 de um log de falha de aplicativo iOS. Uma verificação rápida mostrou que o mesmo valor aparecia no registrador x18 de todos os logs de falha no dispositivo, o que sugeria um sério vazamento de informações.
Em seguida, tentei determinar exatamente o que estava acontecendo com o registrador x18 por meio de experimentação. Eu defini um ponto de interrupção em um aplicativo iOS vazio e usei lldb para ler o valor do registrador x18, confirmando que o vazamento não estava restrito a aplicativos com falha. Depois, tentei ler o valor de x18 usando assembly inline e descobri que o valor obtido não correspondia ao valor mostrado pelo depurador ao usar um comando como reg read x18. Isso sugeriu que talvez o vazamento estivesse realmente em thread_get_state, e que o registrador x18 não continha realmente um ponteiro do kernel enquanto a CPU estava executando no espaço do usuário. Uma prova de conceito rápida que leu o valor de x18 usando thread_get_state confirmou que essa função era de fato a origem do vazamento.
Relatei o problema à Apple em 26 de fevereiro de 2018, no mesmo dia em que o descobri.
Por Brandon Azad