Ataques Spectre: explorando a execução especulativa

Processadores modernos não esperam uma leitura lenta de memória para decidir para onde um desvio vai. Eles adivinham, executam adiante e descartam o trabalho se o palpite estava errado. Como o estado arquitetural (registradores e memória) é restaurado, supunha-se que isso fosse invisível para a segurança. O artigo, de Paul Kocher e coautores (dez no preprint, doze na versão publicada, que acrescenta Jann Horn e Anders Fogh), mostra que a suposição está errada: o trabalho adivinhado pode tocar em dados que não deveria, e o que ele deixa no cache pode ser medido depois.

O artigo foi publicado no IEEE Symposium on Security and Privacy em 2019. Os autores o divulgaram como preprint no arXiv em janeiro de 2018, junto com o ataque relacionado Meltdown, e esta análise segue esse texto público. Isso importa porque o isolamento entre processos, entre uma aba do navegador e o resto do navegador e entre contêineres se apoia na ideia de que a CPU executa fielmente as verificações de segurança de um programa.

Vale conhecer antes: o que é um cache e por que uma leitura em cache é mais rápida, como funcionam a predição de desvios e a execução fora de ordem e o que é um canal lateral.

• Uma nova classe de ataques, chamada Spectre, em que o atacante faz um programa vítima executar de forma especulativa instruções que não rodariam numa execução correta (o artigo as chama de instruções transitórias) e vazar um segredo por um canal lateral.
• Duas variantes concretas. Uma explora desvios condicionais, treinando o preditor e depois fornecendo um índice fora dos limites (contorno de verificação de limites, CVE-2017-5753). A outra explora desvios indiretos, envenenando o branch target buffer para que um "gadget" escolhido na vítima execute de forma especulativa (CVE-2017-5715).
• Provas de conceito funcionais em código nativo e em JavaScript rodando num navegador, que cruzam uma fronteira de processo e uma de sandbox.
• Uma discussão de outras variantes e de opções de mitigação, e um apelo por um contrato claro entre hardware e software sobre o que um processador pode vazar.

O ataque tem três passos. O atacante encontra na vítima um código que possa servir de lado emissor de um canal encoberto, faz o processador executá-lo de forma especulativa e depois lê o resultado pelo cache com medições de tempo do tipo Flush+Reload ou Evict+Reload.

Na variante de desvio condicional, o atacante primeiro chama o código com entradas válidas para que o preditor espere que a verificação de limites passe, e depois o chama com um índice fora do intervalo enquanto o tamanho do array não está no cache. O processador erra o palpite e lê array2[array1[x] * 256], o que traz para o cache uma linha cujo endereço depende do byte secreto. Repetindo com índices diferentes, lê-se a memória byte a byte. Na variante indireta, o atacante treina o branch target buffer a partir do próprio espaço de endereços, já que só importa o endereço virtual do destino e a correspondência com o endereço do desvio pode ser parcial.

Os experimentos são demonstrações em máquinas reais. Os autores testaram Intel Ivy Bridge (i7-3630QM), Haswell (i7-4650U) e Skylake (um Xeon no Google Cloud), AMD Ryzen e alguns processadores ARM da Samsung e da Qualcomm em celulares, em Linux e Windows de 32 e 64 bits.

Estes são os resultados relatados pelos autores.

• A vulnerabilidade foi observada em todos os processadores x86 testados e em alguns ARM, de modo que o problema está na ideia de especulação e não em um fabricante.
• Em código nativo, os autores leram todo o espaço de endereços de um programa vítima, inclusive seus segredos. O código sem otimização do apêndice lê cerca de 10 KB/s em um i7 Surface Pro 3.
• Um programa JavaScript rodando no Chrome leu memória privada do processo que o executa. Como o navegador reduz a precisão do seu temporizador, os autores construíram um relógio de alta resolução com uma thread Web Worker que decrementa um valor compartilhado.
• O mistreinamento entre hyper-threads do mesmo núcleo Intel funcionou, o Skylake mostrou mistreinamento baseado no histórico de desvios e alguns testes de desvio indireto funcionaram no Skylake mas não no Haswell. A indexação do branch target buffer precisou de apenas 20 bits do endereço do desvio nos testes.
• O Meltdown, descrito como relacionado, é diferente: não usa predição de desvios, depende de um problema de privilégio específico da Intel para ler a memória do kernel, e o patch KAISER que o impede não impede o Spectre.
• As mitigações discutidas pelos autores são parciais: instruções de serialização como lfence (cujas garantias não estavam definidas na época), barreiras inseridas pelo compilador com custo alto, desativar o hyper-threading e limpar o estado do preditor, mudanças de microcódigo. Eles chamam todas elas de medidas paliativas.

O artigo é claro e reproduzível no seu núcleo, e seu principal valor é mostrar uma categoria inteira nova de falha. Leia-o com estes pontos em mente.

• É um conjunto de provas de conceito, e não uma medição de quanto software real é explorável. Os autores dizem que a exploração depende da CPU da vítima, das escolhas do compilador e do acesso do atacante.
• O risco é concentrado. O atacante normalmente precisa executar código na mesma CPU da vítima. Os autores consideram concebíveis ataques pela rede, mas tratam código na mesma máquina como o principal perigo. O vazamento é de sigilo, não de integridade.
• A seção de mitigação é provisória. Ela termina com "medidas paliativas até que haja mais pesquisa", e a discussão do que processadores futuros poderiam fazer é especulação. Em nossa leitura, a resposta posterior da indústria (novas instruções, compiladores e sistemas operacionais alterados, novo hardware) confirma a direção, mas está fora deste artigo.
• Há trabalho sobreposto. O próprio artigo registra que se sobrepõe em parte a um trabalho independente do Project Zero do Google.
• O texto que analisamos é o preprint. Detalhes da versão publicada nos anais podem diferir.

• Contratos precisos entre hardware e software que digam qual estado um processador pode vazar, para que se possa demonstrar que um software é seguro.
• Defesas de compilador e de sistema operacional medidas pelo custo de desempenho, já que o artigo avisa que barreiras abrangentes prejudicam o desempenho.
• Ferramentas para encontrar código vulnerável, por exemplo com fuzzing e análise estática, como os autores sugerem.
• Projetos de processador que não deixem o trabalho especulativo alterar estado compartilhado, e outros canais além do cache (contenção de barramento, atividade da ALU, o próprio preditor).