Estudo detalha ataques práticos que contornam as proteções MTE no Chrome e Linux

Índice de Links

Abstrato

1. Introdução

2. Contexto

• Extensão de Marcação de Memória
• Ataque de Execução Especulativa

3. Modelo de Ameaça

4. Encontrar Gadgets de Fuga de Tag

• Modelo de Fuga de Tag
• Fuzzing de Fuga de Tag

5. Gadgets TIKTAG

• TIKTAG-v1: Explorar Redução de Especulação
• TIKTAG-v2: Explorar Encaminhamento Store-to-Load

6. Ataques do Mundo Real

6.1. Atacar o Chrome

7. Avaliação

8. Trabalho relacionado

9. Conclusão e Referências

\

Ataques do Mundo Real

Para demonstrar a explorabilidade dos gadgets TIKTAG na mitigação baseada em MTE, esta secção desenvolve dois ataques do mundo real contra o Chrome e o kernel Linux (Figura 9). Existem vários desafios ao lançar ataques do mundo real usando gadgets TIKTAG. Primeiro, os gadgets TIKTAG devem ser executados no espaço de endereço alvo, exigindo que o atacante construa ou encontre gadgets no sistema alvo. Segundo, o atacante deve controlar e observar o estado da cache para vazar os resultados da verificação de tag. A seguir, demonstramos os ataques do mundo real usando gadgets TIKTAG em dois sistemas do mundo real: o navegador Google Chrome (§6.1) e o kernel Linux (§6.2), e discutimos as estratégias de mitigação.

\ 6.1. Atacar o Chrome

Navegador Um navegador web é uma superfície de ataque primária para ataques baseados na web, pois processa conteúdo web não confiável, como JavaScript e HTML. Primeiro, apresentamos uma visão geral do modelo de ameaça (§6.1.1) e fornecemos um gadget TIKTAG construído no motor JavaScript V8 (§6.1.2). Em seguida, demonstramos a eficácia dos gadgets TIKTAG na exploração do navegador (§6.1.3) e discutimos as estratégias de mitigação (§6.1.4).

\ ==6.1.1. Modelo de Ameaça.== Seguimos o modelo de ameaça típico de ataques ao navegador Chrome, onde o atacante visa explorar vulnerabilidades de corrupção de memória no processo de renderização. Assumimos que o utilizador vítima visita o site controlado pelo atacante, que serve uma página web maliciosa. A página web inclui HTML e JavaScript criados para explorar vulnerabilidades de corrupção de memória no processo de renderização da vítima. Assumimos que todas as técnicas de mitigação de última geração do Chrome estão em vigor, incluindo ASLR [18], CFI [15], isolamento de site [53] e V8 sandbox [56]. Além disso, como uma defesa ortogonal, assumimos que o processo de renderização ativa a marcação MTE aleatória no PartitionAlloc [2].

\ ==6.1.2. Construir Gadget TIKTAG.== No ambiente JavaScript V8, o TIKTAG-v2 foi construído com sucesso e vazou as tags MTE de qualquer endereço de memória. No entanto, não encontrámos um gadget TIKTAG-v1 construível, uma vez que a restrição de tempo rigorosa entre BR e CHECK não era viável na nossa técnica de fuga especulativa do V8 sandbox (§A).

Gadget V8 TikTag-v2. A Figura 8 é o gadget TIKTAG-v2 construído no motor JavaScript V8 e o seu pseudo-código C após compilação JIT. Com este gadget, o atacante pode saber se a tag estimada Tg corresponde à tag Tm atribuída a target_addr. O atacante prepara três arrays, slow, victim, probe, e um valor idx. slow é um Unit8Array com comprimento de 64 e é acedido em BR para acionar a predição incorreta de ramificação. victim é um Float64Array com comprimento 64, que é acedido para acionar o encaminhamento store-to-load. probe é um Uint8Array com comprimento 512, e é acedido em

\ TEST para vazar o resultado da verificação de tag. Um valor idx do tipo Number é usado no acesso fora dos limites de victim. O valor idx é escolhido de modo que victim[idx] aponte para targetaddr com uma tag estimada Tg (i.e., (Tg«56)|targetaddr). Para aceder especulativamente ao target_addr fora do V8 sandbox, aproveitámos a técnica de fuga especulativa do V8 sandbox que descobrimos durante a nossa investigação, que detalhamos em §A. A linha 8 da Figura 8a é o bloco BR do gadget TIKTAG-v2, acionando a predição incorreta de ramificação com slow[0].

\ A linha 12-13 é o bloco CHECK, que executa o encaminhamento store-to-load com victim[idx], acedendo a target_addr com uma tag estimada Tg. Quando este código é compilado JIT (Figura 8b), é realizada uma verificação de limites, comparando idx com victim.length. Se idx for um índice fora dos limites, o código retorna undefined, mas se o campo victim.length demorar muito tempo a ser carregado, o CPU executa especulativamente as seguintes instruções de armazenamento e carregamento.

\ Depois disso, a linha 17 implementa o bloco TEST, que acede ao probe com o valor encaminhado val como índice. Novamente, uma verificação de limites em val contra o comprimento de probe é precedida, mas esta verificação é bem-sucedida, pois PROBEOFFSET é menor que o comprimento do array probe. Como resultado, probe[PROBEOFFSET] é colocado em cache apenas quando o encaminhamento store-to-load é bem-sucedido, o que acontece quando Tg corresponde a Tm.

\ ==6.1.3. Ataque de bypass MTE no Chrome.== A Figura 9a ilustra o ataque geral de bypass MTE no navegador Chrome com primitiva arbitrária de fuga de tag dos gadgets TIKTAG. Assumimos uma vulnerabilidade de buffer overflow no processo de renderização, onde explorar uma vulnerabilidade temporal (por exemplo, use-after-free) é praticamente o mesmo. A vulnerabilidade transborda um ponteiro (i.e., vuln_ptr) para um objeto vulnerável (i.e., objvuln), corrompendo o objeto adjacente (i.e., objtarget).

\ Com a aplicação MTE do PartitionAlloc, dois objetos têm tags diferentes com uma probabilidade de 14/15. Para evitar levantar uma exceção, o atacante precisa garantir que as tags de objvuln e objtarget sejam as mesmas. O TIKTAG-v2 pode ser utilizado para vazar a tag de objvuln ( 1 ) e objtarget ( 2 ). Se ambas as tags vazadas forem as mesmas, o atacante explora a vulnerabilidade, o que não levantaria uma falha de verificação de tag ( 3 ). Caso contrário, o atacante liberta e realoca objtarget e volta ao primeiro passo até que as tags correspondam.

\ ==Acionar Canal Lateral de Cache.== Para explorar com sucesso um gadget TIKTAG, o atacante precisa satisfazer os seguintes requisitos:

i) treino de ramificação,

ii) controlo de cache, e

iii) medição de cache. Todos os três requisitos podem ser atendidos em JavaScript.

Primeiro, o atacante pode treinar o preditor de ramificação executando o gadget com slow[0] diferente de zero e idx dentro dos limites, e acionar a predição incorreta de ramificação em BR com valor zero em slow[0] e idx fora dos limites.

Segundo, o atacante pode despejar as linhas de cache de slow[0], victim.length e probe[PROBE_OFFSET] com técnicas de despejo de cache JavaScript [8, 21, 70].

Terceiro, o atacante pode medir o estado da cache de probe[PROBE_OFFSET] com um temporizador de alta resolução baseado em SharedArrayBuffer [16, 58].

\ ==Explorar Vulnerabilidades de Corrupção de Memória.== Dadas as tags MTE vazadas, o atacante pode explorar vulnerabilidades de corrupção de memória espacial e temporal no renderizador. A estratégia de ataque é praticamente a mesma dos ataques tradicionais de corrupção de memória, mas deve garantir que a vulnerabilidade não levante uma falha de verificação de tag utilizando as tags vazadas. Detalhamos ainda mais a estratégia de ataque em §C.

\ ==6.1.4. Mitigação.== Para mitigar os ataques de bypass MTE baseados em gadgets TIKTAG no processo de renderização do navegador, as seguintes mitigações podem ser empregues:

i) Sandbox consciente de execução especulativa: Para impedir que atacantes lancem ataques baseados em TIKTAG a partir de um ambiente em sandbox como o V8 sandbox, o sandbox pode ser fortificado prevenindo qualquer acesso especulativo à memória além da região de memória do sandbox. Embora os navegadores web modernos empreguem um sandbox para isolar conteúdos web não confiáveis do renderizador, muitas vezes negligenciam caminhos especulativos.

\ Por exemplo, o Chrome V8 sandbox [56] e o Safari Webkit sandbox [1] não medeiam completamente os caminhos especulativos [27]. Com base nas técnicas atuais de compressão de ponteiros [64], os caminhos especulativos podem ser restritos à região do sandbox mascarando os bits altos dos ponteiros.

\ ii) Barreira de especulação: Como sugerido em §5, colocar uma barreira de especulação após BR para potenciais gadgets TIKTAG pode prevenir ataques de fuga especulativa de tag. No entanto, esta mitigação pode não ser aplicável no ambiente crítico de desempenho do navegador, pois pode introduzir sobrecarga significativa de desempenho.

\ iii) Prevenção de construção de gadget: Como sugerido em §5.2, o gadget TIKTAG-v2 pode ser mitigado inserindo instruções de preenchimento entre instruções de armazenamento e carregamento. Um gadget TIKTAGv1, embora não tenhamos encontrado um explorável, pode ser mitigado inserindo instruções de preenchimento entre uma ramificação e acessos à memória, conforme descrito em §5.1.

\ 6.2. Atacar o Kernel Linux

O kernel Linux em ARM é amplamente usado para dispositivos móveis, servidores e dispositivos IoT, tornando-o um alvo de ataque atrativo. Explorar uma vulnerabilidade de corrupção de memória no kernel pode escalar o privilégio do utilizador e, portanto, o MTE é um mecanismo de proteção promissor para o kernel Linux. Os ataques baseados em TIKTAG contra o kernel Linux apresentam desafios únicos diferentes do ataque ao navegador (§6.1).

\ Isto porque o espaço de endereço do atacante está isolado do espaço de endereço do kernel onde o gadget será executado. A seguir, primeiro apresentamos uma visão geral do modelo de ameaça do kernel Linux (§6.2.1) e fornecemos um gadget TIKTAG de prova de conceito que descobrimos no kernel Linux (§6.2.2). Finalmente, demonstramos a eficácia dos gadgets TIKTAG na exploração de vulnerabilidades do kernel Linux (§6.2.3).

\ ==6.2.1. Modelo de Ameaça.== O modelo de ameaça aqui é praticamente o mesmo dos ataques típicos de escalada de privilégios contra o kernel. Especificamente, focamo-nos no kernel Linux Android baseado em ARM, fortificado com proteções padrão do kernel (por exemplo, KASLR, SMEP, SMAP e CFI). Além disso, assumimos que o kernel é fortificado com uma solução de marcação aleatória MTE, semelhante às soluções MTE prontas para produção, Scudo [3].

\ Especificamente, cada objeto de memória é marcado aleatoriamente, e uma tag aleatória é atribuída quando um objeto é libertado, prevenindo assim corrupções de memória espaciais e temporais. O atacante é capaz de executar um processo sem privilégios e visa escalar o seu privilégio explorando vulnerabilidades de corrupção de memória no kernel. Assume-se que o atacante conhece vulnerabilidades de corrupção de memória do kernel, mas não conhece qualquer tag MTE da memória do kernel. Acionar corrupção de memória entre objetos do kernel com

\ tags incompatíveis levantaria uma falha de verificação de tag, o que é indesejável para explorações do mundo real. Um desafio crítico neste ataque é que o gadget deve ser construído reutilizando o código do kernel existente e executado pelas chamadas de sistema que o atacante pode invocar. Como a arquitetura ARMv8 separa as tabelas de páginas do utilizador e do kernel, os gadgets do espaço do utilizador não podem aceder especulativamente à memória do kernel. Esta configuração é muito diferente do modelo de ameaça de ataque ao navegador (§6.1), que aproveitou o código fornecido pelo atacante para construir o gadget. Também excluímos a construção de gadget baseada em eBPF [17, 28], porque o eBPF não está disponível para o processo Android sem privilégios [33].

\ ==6.2.2. Gadget TikTag do Kernel==. Como descrito em §4.1, os gadgets TIKTAG devem atender a vários requisitos, e cada requisito implica desafios no ambiente do kernel.

Primeiro, em BR, uma predição incorreta de ramificação deve ser acionada com cond_ptr, que deve ser controlável a partir do espaço do utilizador. Como os processadores AArch64 recentes isolam o treino de predição de ramificação entre o utilizador e o kernel [33], o treino de ramificação precisa ser realizado a partir do espaço do kernel.

Segundo, em CHECK, guessptr deve ser desreferenciado. guessptr deve ser criado a partir do espaço do utilizador de modo que incorpore uma tag de estimativa (Tg) e aponte para o endereço do kernel (i.e., target_addr) para vazar a tag (Tm). Ao contrário do ambiente JavaScript do navegador (§6.1), os dados fornecidos pelo utilizador são fortemente sanitizados nas chamadas de sistema, por isso é difícil criar um ponteiro arbitrário do kernel.

\ Por exemplo, accessok() garante que o ponteiro fornecido pelo utilizador aponte para o espaço do utilizador, e a macro arrayindexnospec previne o acesso especulativo fora dos limites com o índice fornecido pelo utilizador. Assim, guessptr deve ser um ponteiro do kernel existente, especificamente o ponteiro vulnerável que causa corrupção de memória. Por exemplo, um ponteiro pendente em use-after-free (UAF) ou um ponteiro fora dos limites em buffer overflow pode ser usado. Por último, em TEST, testptr deve ser desreferenciado, e testptr deve ser acessível a partir do espaço do utilizador. Para facilitar a medição do estado da cache, test_ptr deve ser um ponteiro do espaço do utilizador fornecido através de um argumento de chamada de sistema.

\ ==Gadgets Descobertos.== Analisámos manualmente o código-fonte do kernel Linux para encontrar o gadget TIKTAG que atende aos requisitos mencionados anteriormente. Como resultado, encontrámos um gadget TIKTAG-v1 potencialmente explorável em sndtimeruserread() (Figura 10). Este gadget cumpre os requisitos do TIKTAG-v1 (§5.1). Na linha 10 (i.e., BR), a declaração switch aciona predição incorreta de ramificação com um valor controlável pelo utilizador tu->tread (i.e., condptr). Nas linhas 14-17 (i.e., CHECK), tread (i.e., guessptr) é desreferenciado por quatro instruções de carregamento. tread aponta para um objeto struct sndtimer_tread64 que o atacante pode alocar e libertar arbitrariamente.

\ Se uma vulnerabilidade temporal transformar tread num ponteiro pendente, ele pode ser usado como guessptr. Na linha 20, (i.e., TEST), um buffer de ponteiro do espaço do utilizador (i.e., testptr) é desreferenciado em copytouser. Como este gadget não é diretamente acessível a partir do espaço do utilizador, fizemos uma ligeira modificação ao código do kernel; removemos o retorno antecipado para o caso padrão na linha 6. Isto garante que o buffer seja apenas acedido no caminho especulativo para observar a diferença de estado da cache devido à execução especulativa.

\ Embora esta modificação não seja realista num cenário do mundo real, demonstra a potencial explorabilidade do gadget se forem feitas alterações de código semelhantes. Descobrimos vários gadgets potencialmente exploráveis adicionais, mas não conseguimos observar a diferença de estado da cache entre a correspondência e não correspondência de tag. Ainda assim, pensamos que há forte potencial para explorar esses gadgets. Lançar ataques baseados em TIKTAG envolve engenharia complexa e sensível, e assim não conseguimos experimentar com todos os casos possíveis.

\ Especialmente, o TIKTAG-v1 depende da redução de especulação em eventos de caminho errado, que também podem incluir falhas de tradução de endereço ou outras exceções no caminho de predição incorreta de ramificação. Como as chamadas de sistema envolvem fluxos de controlo complexos, a redução de especulação pode não ser acionada como esperado. Além disso, vários gadgets podem tornar-se exploráveis quando o código do kernel muda. Por exemplo, um gadget TIKTAG-v1 em ip6mr_ioctl() não exibiu um comportamento de fuga de tag MTE quando chamado a partir do seu caminho de chamada de sistema (i.e., ioctl). No entanto, o gadget teve fuga de tag quando foi portado para outras syscalls (por exemplo, write) com um fluxo de controlo simples.

\ ==6.2.3. Ataque de bypass MTE no Kernel.== A Figura 9b ilustra os ataques de bypass MTE no kernel Linux. Tomando uma vulnerabilidade use-afterfree como exemplo, assumimos que o atacante identificou um gadget TIKTAG correspondente, SysTikTagUAF(), capaz de vazar o resultado da verificação de tag do ponteiro pendente criado pela vulnerabilidade. Por exemplo, o gadget TIKTAG-v1 em sndtimeruser_read() (Figura 10) pode vazar o resultado da verificação de tag de tread, que pode tornar-se um ponteiro pendente por uma vulnerabilidade use-after-free ou double-free.

\ O ataque prossegue da seguinte forma: Primeiro, o atacante liberta um objeto do kernel (i.e., objvuln) e deixa o seu ponteiro (i.e., vuln_ptr) como um ponteiro pendente ( 1 ). Em seguida, o atacante aloca outro objeto do kernel (i.e., objtarget) no endereço de objvuln com SysAllocTarget() ( 2 ). Depois, o atacante invoca SysTikTag() com um buffer do espaço do utilizador (i.e., ubuf) ( 3 ), e vaza o resultado da verificação de tag (i.e., Tm == Tg) medindo a latência de acesso de ubuf ( 4 ). Se as tags corresponderem, o atacante aciona SysExploitUAF(), uma chamada de sistema que explora a vulnerabilidade use-after-free ( 5 ). Caso contrário, o atacante realoca objtarget até que as tags correspondam.

\ ==Acionar Canal Lateral de Cache.== Como em §6.1.3, uma exploração bem-sucedida de gadget TIKTAG requer i) treino de ramificação, ii) controlo de cache e iii) medição de cache. Para o treino de ramificação, o atacante pode treinar o preditor de ramificação e acionar especulação com condições de ramificação controladas pelo utilizador a partir do espaço do utilizador. Para controlo de cache, o atacante pode despejar o buffer do espaço do utilizador (i.e., ubuf), enquanto o endereço de memória do kernel pode ser despejado por ricochete de linha de cache [25]. Para medição de cache, a latência de acesso de ubuf pode ser medida com o contador virtual (i.e., CNTVCT_EL0) ou um temporizador baseado em contador de memória (i.e., resolução próxima do ciclo do CPU).

\ ==Explorar Vulnerabilidades de Corrupção de Memória.== Os gadgets TIKTAG permitem contornar o MTE e explorar vulnerabilidades de corrupção de memória do kernel. O atacante pode invocar o gadget TIKTAG no kernel para acionar especulativamente a corrupção de memória e obter o resultado da verificação de tag. Em seguida, o atacante pode obter o resultado da verificação de tag e acionar a corrupção de memória apenas se as tags corresponderem. Detalhamos o processo de ataque de bypass MTE do kernel Linux em §D.

\ ==6.2.4. Mitigação.== Para mitigar o gadget TIKTAG no kernel Linux, os programadores do kernel devem considerar as seguintes mitigações:

i) Barreira de especulação: As barreiras de especulação podem efetivamente mitigar o gadget TIKTAG-v1 no kernel Linux. Para prevenir que atacantes vazem o resultado da verificação de tag através do buffer do espaço do utilizador, as funções do kernel que acedem a endereços do espaço do utilizador, como copytouser e copyfromuser, podem ser fortificadas com barreiras de especulação. Como descrito em §5.1, vazar resultados de verificação de tag com acesso de armazenamento pode ser mitigado colocando uma barreira de especulação antes do acesso de armazenamento (i.e., TEST).

\ Por exemplo, para mitigar os gadgets que aproveitam copytouser, uma barreira de especulação pode ser inserida antes da invocação de copytouser. Para gadgets que utilizam acesso de carregamento ao buffer do espaço do utilizador, as barreiras mitigam os gadgets se inseridas entre a ramificação e o acesso à memória do kernel (i.e., CHECK). Por exemplo, para mitigar os gadgets que aproveitam copyfromuser, os programadores do kernel devem analisar cuidadosamente a base de código do kernel para encontrar o padrão da ramificação condicional, acesso à memória do kernel e copyfromuser(), e inserir uma barreira de especulação entre a ramificação e o acesso à memória do kernel.

\ ii) Prevenção de construção de gadget: Para eliminar potenciais gadgets TIKTAG no kernel Linux, o código-fonte do kernel pode ser analisado e corrigido. Como os gadgets TIKTAG também podem ser construídos por otimizações do compilador, uma análise binária pode ser conduzida. Para cada gadget descoberto, as instruções podem ser reordenadas ou instruções adicionais podem ser inseridas para prevenir a construção do gadget, seguindo as estratégias de mitigação em §5.1 e §5.2.

:::info Autores:

1. Juhee Kim
2. Jinbum Park
3. Sihyeon Roh
4. Jaeyoung Chung
5. Youngjoo Lee
6. Taesoo Kim
7. Byoungyoung Lee

:::

:::info Este artigo está disponível no arxiv sob licença CC 4.0.

:::

\