GoFetch: um novo ataque de canal lateral usando prefetcher dependente de memória de dados
(gofetch.fail)- O prefetcher dependente de memória de dados (DMP) pode tratar valores de dados do código criptográfico como se fossem endereços, permitindo o vazamento de chaves secretas até em implementações de tempo constante
- Em CPUs Apple m-series, quando um valor carregado da memória parece um ponteiro, o DMP tenta dereferenciá-lo, abalando a premissa de programação em tempo constante de separação entre dados e endereços
- Os pesquisadores demonstraram extração de chave end-to-end no Apple m1 contra OpenSSL Diffie-Hellman, descriptografia RSA em Go, CRYSTALS-Kyber e CRYSTALS-Dilithium, e confirmaram comportamento semelhante do DMP também no m2 e m3
- No m3, o bit DIT desativa o DMP de forma eficaz, mas isso não se aplica ao m1 e m2; além disso, o bit de configuração HID descoberto em abril de 2024 é difícil de usar de imediato por falta de suporte no kernel do macOS
- As mitigações incluem manter o software atualizado, usar os bits DIT/DOIT em algumas CPUs, blindagem de entrada e evitar compartilhamento de hardware; a avaliação de vulnerabilidade exige criptoanálise e inspeção de código
O núcleo do ataque GoFetch
- GoFetch é um ataque de canal lateral de microarquitetura que explora o prefetcher dependente de memória de dados (DMP)
- Ele permite extrair chaves secretas até de implementações criptográficas escritas em tempo constante
- Os alvos demonstrados pelos pesquisadores foram os seguintes
- OpenSSL Diffie-Hellman Key Exchange
- Go RSA decryption
- CRYSTALS-Kyber
- CRYSTALS-Dilithium
- O artigo e as ferramentas estão disponíveis em Paper e Tools
Como o DMP quebra a premissa de tempo constante
- O DMP das CPUs Apple m-series é ativado quando os dados carregados da memória parecem um valor de ponteiro e tenta dereferenciá-los
- A programação em tempo constante exige separar dados e endereços para que ramificações, loops, acessos à memória e índices de array não variem conforme valores secretos
- Mesmo que o código da vítima siga essa regra, o DMP pode criar por conta própria, em nível de hardware, acessos à memória dependentes de segredos
- Como resultado, surgem diferenças de tempo observáveis em código que deveria ser de tempo constante, expondo-o a ataques de extração de chave
Procedimento do ataque
- O atacante monta entradas escolhidas para a operação criptográfica de modo que um valor intermediário que pareça ponteiro só apareça quando parte da chave secreta for adivinhada corretamente
- Em seguida, usa análise de tempo de cache para verificar se o DMP realizou a dereferência e confirmar se o palpite estava certo
- Quando um palpite correto é confirmado, o mesmo método é usado para adivinhar o próximo grupo de bits da chave
- Com esse procedimento, torna-se possível realizar extração de chave end-to-end em implementações de criptografia clássica e pós-quântica
Processadores afetados e observações
- O ataque GoFetch end-to-end foi executado em hardware com processador Apple m1
- As CPUs m2 e m3 também exibem padrões de ativação do DMP exploráveis de forma semelhante
- Outras variantes da m-series, como o m2 Pro, não foram testadas, mas como usam a mesma microarquitetura dos modelos básicos, é possível que também tenham DMP explorável
- A microarquitetura Intel 13th Gen Raptor Lake também possui DMP
- Porém, como o critério de ativação é mais restrito, ela é robusta contra o ataque GoFetch
Diferença em relação ao Augury
- O DMP da Apple m-series foi descoberto inicialmente pelo Augury
- O Augury considerava que o DMP podia misturar dados e endereços sob certas condições
- Os pesquisadores do GoFetch avaliaram que os critérios de ativação do DMP organizados pelo Augury eram excessivamente restritivos
- No comportamento real, qualquer valor carregado da memória pode se tornar candidato a dereferência, o que leva a ataques end-to-end contra código criptográfico real de tempo constante
Contexto sobre cache e prefetcher
- Processadores modernos usam cache para reduzir a latência de acesso à memória
- Dados acessados anteriormente permanecem no cache, tornando acessos posteriores mais rápidos
- Um atacante executando na mesma máquina pode observar o estado compartilhado do cache e inferir os padrões de acesso da vítima
- Prefetchers comuns preveem os próximos endereços de acesso com base no rastreamento de endereços de memória acessados anteriormente
- O DMP determina quais dados trazer considerando também o conteúdo da memória, para lidar com padrões irregulares de acesso como travessia de listas encadeadas
- Esse comportamento mistura dados e endereços de memória em nível de hardware, podendo fazer toda a pilha de computação se comportar como se fosse non-constant-time
Como avaliar vulnerabilidade e mitigações
- Para determinar se uma implementação é vulnerável, é preciso entender em que momento e de que forma valores intermediários podem parecer ponteiros de maneira dependente do segredo
- Essa avaliação exige criptoanálise e inspeção de código, é manual e lenta, além de não conseguir excluir outras formas de ataque
- Em alguns processadores, é possível desativar o DMP
- Em abril de 2024, Hector Martin (marcan) descobriu o bit de configuração HID
SYS_APL_HID11_EL1[30], que desativa o DMP nas CPUs m1 e m2- Essa configuração de chicken bit exige suporte do kernel
- Atualmente, o macOS não oferece esse suporte
- Mais informações estão no post de @marcan
- Recomenda-se aos usuários usar software recente e aplicar atualizações regularmente
- Desenvolvedores de bibliotecas criptográficas podem configurar os bits DIT/DOIT em CPUs compatíveis
- A blindagem de entrada pode ajudar, em alguns esquemas criptográficos, a evitar valores intermediários controlados pelo atacante
- Evitar compartilhamento de hardware, de forma que o atacante não consiga medir a ativação do DMP, pode reforçar ainda mais a segurança dos protocolos criptográficos
Divulgação e atualizações posteriores
- Os pesquisadores divulgaram os resultados à Apple em 5 de dezembro de 2023, 107 dias antes do lançamento público
- Em agosto de 2024, o GoFetch ganhou o prêmio Pwnie Award 2024 Best Cryptographic Attack
- Em dezembro de 2024, um estudo posterior fez engenharia reversa da semântica do DMP da Intel e mostrou uma técnica capaz de vazar informações mesmo quando o DMP dereferencia ponteiros inválidos
- O artigo de acompanhamento é Peek-a-Walk: Leaking Secrets via Page Walk Side Channels
- O código está no repositório GitHub do Peek-a-Walk
1 comentários
Opiniões no Hacker News
Se estamos em uma era em que há coisas como núcleos de eficiência, talvez as arquiteturas modernas também precisem de núcleos criptográficos
Esses núcleos deveriam oferecer explicitamente garantias relacionadas a algoritmos de tempo constante e não fazer coisas como pré-busca ou predição de desvios
Algo parecido com o Itanium, mas limitado a um “processador criptográfico”; como teria muitos recursos a menos, em princípio a área de silício do próprio núcleo também não deveria ser grande
Para quem implementa código criptográfico, esse tipo de problema deve ser difícil a ponto de dar vontade de beber. Mesmo no melhor cenário já é uma batalha difícil, e, ainda que você implemente tudo corretamente, inúmeros recursos atuais e futuros dos processadores podem quebrar seu código a qualquer momento
Mas um coprocessador criptográfico é uma solução destrutiva demais. Seria preciso criar uma montanha de infraestrutura para alternar para esse núcleo e voltar, compartilhar memória, etc.
O pior é que não dá simplesmente para mover só a multiplicação RSA para esse núcleo e pronto. A chave deve ter sido analisada em algum lugar; o parser também teria que rodar no núcleo criptográfico? E se ela vier pela rede? Mesmo que todas as chaves sejam protegidas, tudo bem se um canal lateral de CPU vazar a mensagem criptografada? Podemos considerar que está tudo bem porque não é a chave?
O motivo de esses ataques não aparecerem tanto em código não criptográfico é que encontrar o alvo varia demais de aplicação para aplicação, enquanto em bibliotecas criptográficas todo mundo concorda que vazamento de chave é ruim
No fim, projetistas de processadores não deveriam quebrar pressupostos e, no mínimo, deveriam conversar conosco antes de fazer isso
A unidade de abstração provavelmente tenderia a ser no nível de thread
https://support.apple.com/guide/security/secure-enclave-sec5...
Mas arquiteturas de nuvem otimizadas para custo acabaram se inclinando para hardware de consumidor e tomaram o mercado de CPUs; agora, mesmo para aplicações em grande escala, a única opção realista são CPUs de consumidor
Para viabilizar novos algoritmos, também pode ser uma boa adicionar algumas instruções de operações criptográficas primitivas
Segundo o artigo, “a OpenSSL informou que ataques locais por canal lateral estão fora de seu modelo de ameaça, e a equipe Go Crypto considera a severidade desse ataque baixa”
A conclusão final desses ataques por canal lateral seria uma CPU que não faz nenhuma otimização e em que todas as instruções levam o mesmo número de ciclos em todas as situações
Mas isso nunca vai acontecer. Ninguém quer uma CPU lenta
Se não puder ser explorado remotamente, não acho que seja algo com que se preocupar. Claro, virtualização em nuvem multi-inquilino está fora de questão
Sem execução especulativa, sem pré-busca, algo como aquele pipeline de 5 estágios das aulas de Arquitetura de Computadores 101
Existem alguns provedores de nuvem que alugam tempo de computação em Mac Mini montado em rack, mas não são muitos, e mesmo esses são para cargas de trabalho ou tarefas de build muito específicas
Pode ser um problema para quem paga caro por esses serviços, mas a esmagadora maioria dos dispositivos Apple Silicon nunca vai hospedar serviços de nuvem
Se você isolar o código em um núcleo específico, supondo que tudo funcione como pretendido, o exploit não conseguirá comprometer outros inquilinos
Sobre “é possível desativar o DMP?”, diz: “Sim, mas apenas em alguns processadores. Em CPUs M3, definir o bit DIT desativa efetivamente o DMP, mas isso não acontece no M1 e no M2”
Com certeza não deve haver algum chicken bit em algum lugar para desligar isso?
Dá para fazer em Swift ou precisa de assembly?
Pelo que li, bibliotecas como a libsodium parecem só precisar definir o bit de desativação antes de operações criptográficas sensíveis no M3 ou posterior
Também parece ser necessário descobrir previamente alguns aspectos da chave
Muito elegante, mas não parece particularmente prático
Lembrei do ataque Augury de 2022. Ele também explorava a pré-busca DMP das CPUs Apple Silicon
[1]: https://www.prefetchers.info
Por que a Apple tem tantos backdoo… bugs puramente acidentais de hardware?
Respondendo a essa bobagem de teoria conspiratória sobre backdoors: como as pessoas querem CPUs rápidas, processadores têm caches e diferenças de tempo. Não dá para ter tempo constante e alto desempenho ao mesmo tempo, e a Apple não é a única empresa que tem pré-busca
Aqui está a documentação da Apple sobre como ativar operações de tempo constante para criptografia. Parece até que foi projetado intencionalmente no hardware. Muito estranho: https://developer.apple.com/documentation/xcode/writing-arm6...
Se você escreve rotinas criptográficas, use a biblioteca criptográfica da plataforma ou siga a documentação
https://developer.apple.com/documentation/xcode/writing-arm6...
Agora verificações de malware e antivírus também passaram a fazer sentido no Mac e no iPad
O atacante precisa estar em execução no mesmo hardware