Vejamos a função antes do patch (tentei rotular as linhas relevantes):

• O loop em [1] conta o número de IOHIDElementValues no buffer e armazena esta contagem em cookieCount.
• A verificação em [2] (combinada com a condição do loop while) garante que o campo length de cada cabeçalho não se estenda para fora dos limites do buffer elementData (nem pode ficar aquém do final do buffer, embora isso seja menos relevante).
• Uma vez que todos os elementos foram contados e verificados por este loop, um buffer cookies é alocado no heap em [3] com um tamanho de cookieCount * 4 (ou um buffer de pilha é usado se cookieCount for suficientemente pequeno).
• Um segundo loop em [4] faz então uma segunda passagem pelo buffer, analisando novamente os IOHIDElementValues.
• Objetos OSData são criados para armazenar o valor de cada elemento em [5], usando o campo length que foi validado no primeiro loop.
• Em [6], o cookie de cada elemento é escrito no array cookies alocado em [3].

Então, qual é o problema? Esta função se comporta de forma totalmente correta quando elementData é não volátil; o problema surge quando o método é chamado com memória compartilhada. Conheça o método IOHIDInterface::SetElementValues_Impl do DriverKit:

Aqui, postElementTransaction é chamado com md->getBytesNoCopy(), memória compartilhada com o espaço do usuário, violando a suposição de que elementData é não volátil. O conteúdo do buffer elementData pode mudar após o loop em [1], mas antes do loop em [4], então o que isso significa para um atacante?

Existem duas maneiras de um atacante abusar disso:

• A primeira é trocar o length de um IOHIDElementValueHeader pequeno no final do buffer por um valor muito maior. Isso significa que quando o OSData em [5] for criado, ele se estenderá muito além dos limites do buffer elementData, permitindo que um atacante leia dados fora dos limites usando IOHIDInterface::GetElementValues_Impl.
• A segunda é trocar o length de um IOHIDElementValueHeader grande no início do buffer por um valor muito menor. Isso fará com que o loop em [4] analise muitos mais cabeçalhos do que foram originalmente contados no loop em [1], então, quando os cookies forem escritos no array cookies em [6], eles transbordarão para fora do array, pois index nunca é validado contra cookieCount.

Na prática, isso permite que um atacante leia dados do heap do kernel fora dos limites de tamanho arbitrário e escreva dados arbitrários (novamente de tamanho arbitrário) fora dos limites no heap do kernel. Estas são duas primitivas poderosas.

Vencendo a corrida

Com condições de corrida, sempre procuramos maneiras de determinar se a corrida foi vencida com sucesso, para podermos continuar tentando até conseguir, tornando nosso gatilho determinístico. Felizmente, no caso desta condição de corrida, podemos fazer exatamente isso.

Para a variante de leitura fora dos limites, coloco mais um IOHIDElementValueHeader após o cabeçalho cujo length estou alterando, com seu value definido como a constante reconhecível de 0xD1AB011CAC1DF00D. Então, ao ler o valor do elemento de volta, sei que venci a corrida se vir o familiar cabeçalho 0xD1AB011CAC1DF00D no início dos dados retornados.

Para a variante de escrita fora dos limites, coloco um IOHIDElementValueHeader após o cabeçalho cujo length estou alterando, mas antes dos cabeçalhos cujos cookies serão estourados, desta vez com o value reconhecível de 0xD15EA5ED. Este cabeçalho será encapsulado dentro do value do elemento maior no caso de não vencermos a corrida, então o cabeçalho só será analisado e o valor do elemento será definido como 0xD15EA5ED se vencermos a corrida. Ao ler de volta o valor do elemento, sei se fui bem-sucedido.

A correção da Apple

Para corrigir o problema, a Apple optou por adicionar um terceiro loop entre o loop [1] e o loop [4], validando cada campo length e armazenando-o em cache em um novo array dataLengths, garantindo que o número de elementos não tivesse mudado. O loop final usa então os comprimentos em cache para seus cálculos, evitando ler do buffer mais uma vez.

Problemas com a exploração

O principal obstáculo a superar ao explorar este problema é que o buffer do qual estamos estourando pertence a KHEAP_DATA_BUFFERS, então os alvos de exploração são limitados. Nesta prova de conceito, optei por mirar nos cabeçalhos kmsg, pois são uma das poucas estruturas em KHEAP_DATA_BUFFERS que contêm ponteiros do kernel. A primitiva de "kfree arbitrário" que obtive com essa abordagem é a mesma primitiva usada no exploit multicast_bytecopy; no entanto, o array IOSurfaceClient agora é protegido por PAC e clientes forjados precisam ter um ponteiro válido de volta para o IOSurfaceRootUserClient que os criou, tornando isso um alvo de leitura/escrita do kernel não mais desejável.

Compilando e instalando

A Apple não facilitou a compilação e instalação de extensões DriverKit personalizadas, especialmente sem uma conta paga de Apple Developer, mas é possível.

Antes de começar, recomendo:

• Desativar o SIP
• Definir os boot-args amfi_get_out_of_my_way=1 cs_enforcement_disable=1
• Executar systemextensionsctl developer on
• Reiniciar o computador

Depois disso, você deve conseguir selecionar sua equipe de desenvolvedor nas configurações do projeto Xcode e o projeto será compilado com sucesso. Você pode então executar o HIDDriverLoader, usar "Install Dext" para instalar a extensão DriverKit e "Trigger Exploit" para, você adivinhou, acionar o exploit.

Se isso falhar, você também pode tentar compilar sem assinatura usando:

E então assinar manualmente usando:

Substituindo self-sign-cert pelo nome de um certificado autoassinado no seu chaveiro.

Obrigado por ler :)