ZenHammer: ataque Rowhammer contra plataformas baseadas em AMD Zen
(comsec.ethz.ch)- Bit flips de Rowhammer ocorreram até mesmo em sistemas DDR4 com AMD Zen 2 e Zen 3 com mitigação TRR aplicada, mostrando que plataformas AMD também podem representar uma superfície de ataque real
- A equipe de pesquisa aplicou a técnica DRAMA adaptada para AMD para fazer engenharia reversa das funções secretas de endereçamento da DRAM e confirmou que, por causa do remapeamento de endereços do sistema, é necessário tratar offsets de endereços físicos
- O fuzzer ZenHammer provocou bit flips em 7 dispositivos no Zen 2 e 6 no Zen 3 entre 10 dispositivos DDR4, incluindo Samsung, Micron e SK Hynix, e os dispositivos Zen 3 se mostraram mais vulneráveis do que Intel Coffee Lake
- Os ataques existentes contra tabelas de páginas, corrupção de chave pública RSA-2048 e
sudoers.sopuderam ser montados em 7/6/4 dispositivos, respectivamente, e o tempo médio para encontrar bit flips exploráveis foi de 164/267/209 segundos - Na avaliação do DDR5 no Zen 4, cerca de 42.000 bit flips ocorreram em 1 de 10 dispositivos, mas falharam nos outros 9, indicando que o DDR5 ainda exige pesquisa adicional de padrões
Bit flips de Rowhammer também ocorrem no AMD Zen
- ZenHammer provoca bit flips de Rowhammer em dispositivos DDR4 em sistemas AMD Zen 2 e Zen 3 com mitigação TRR aplicada
- Foi confirmado que sistemas AMD, assim como sistemas Intel, também podem ter vulnerabilidade a Rowhammer
- Considerando que a AMD tem cerca de 36% de participação no mercado de CPUs x86 para desktop, a superfície de ataque não é pequena
- Dispositivos DRAM são difíceis de corrigir facilmente depois de implantados, e estudos anteriores já mostraram que ataques Rowhammer podem ser práticos em vários ambientes
Engenharia reversa da função de endereçamento DRAM da AMD e otimização do hammering
- A técnica DRAMA foi aplicada de forma adaptada a sistemas AMD para fazer engenharia reversa das funções secretas de endereçamento da DRAM
- A rotina de temporização foi modificada para obter resultados mais estáveis
- Por causa do remapeamento de endereços do sistema, foi necessário aplicar um offset de endereço físico antes de recuperar a função de endereçamento DRAM, o que permitiu restaurar completamente a função
- Usar apenas a função de endereçamento recuperada resultou em um número limitado de bit flips
- No Zen 2, bit flips foram confirmados em apenas 5 de 10 dispositivos
- No Zen 3, bit flips foram confirmados em 0 de 10 dispositivos
Sincronização de refresh e sequência de comandos
- Assim como em pesquisas anteriores, como SMASH e Blacksmith, a sincronização de refresh foi um fator importante para provocar bit flips
- Na AMD, realizar medições contínuas de temporização em linhas não repetidas foi eficaz para uma sincronização de refresh precisa e confiável
- Em sistemas AMD Zen+/3, a taxa de ativação de padrões Rowhammer não uniformes foi significativamente menor do que no Intel Coffee Lake
- A sequência ideal de comandos de hammering usava carregamentos
MOVnormais eCLFLUSHOPTpara expulsar o aggressor do cache, com um estilo “scatter” que faz flush logo após o acesso ao aggressor - Diferentemente do Zen 2, no Zen 3 não foi necessário um fence explícito após o flush
- O tipo de fence e a política de escalonamento de fence também afetaram os resultados, e a equipe propôs 6 políticas de reconhecimento de padrão e evasão de cache, testando 6 horas por dispositivo
- Na maioria dos dispositivos Zen 2,
SP_nonefoi o ideal - Na maioria dos casos no Zen 3,
SP_pairfoi mais adequado
- Na maioria dos dispositivos Zen 2,
Resultados da avaliação em DDR4 e possibilidade de exploração
- A avaliação foi realizada em 10 dispositivos DRAM DDR4, incluindo Samsung, Micron e SK Hynix
- O fuzzer ZenHammer foi executado por 3 horas para cada combinação dos tipos de fence
mfence,sfencee cada política de escalonamento de fence - Após cada execução, foi feito um minisweep em uma faixa de 4MiB com todos os padrões encontrados para determinar o melhor padrão, e depois o melhor padrão da melhor política foi aplicado em sweep sobre uma região contígua de memória de 256MB
- Como resultado, ocorreram bit flips em 7 dispositivos no Zen 2 e 6 no Zen 3 entre 10 dispositivos DRAM DDR4
- A explorabilidade dos bit flips foi avaliada com três ataques de pesquisas anteriores
- Ataque ao page frame number de uma entrada da tabela de páginas para pivotar para uma página de tabela de páginas controlada pelo atacante
- Ataque à chave pública RSA-2048 que permite recuperar a chave privada relacionada usada na autenticação de host SSH
- Ataque à lógica de verificação de senha da biblioteca
sudoers.so, permitindo obter privilégios de root
- Os ataques existentes puderam ser montados em 7/6/4 dispositivos, respectivamente, e o tempo médio para encontrar bit flips exploráveis foi de 164/267/209 segundos
Avaliação do DDR5, código público e cronograma de divulgação
- Também foi feita engenharia reversa da função DRAM DDR5 no AMD Zen 4 e foram avaliados 10 dispositivos DDR5
- O ZenHammer provocou cerca de 42.000 bit flips em 1 dos 10 dispositivos DDR5
- Este é o primeiro caso reportado publicamente de bit flips em DDR5 em um sistema comercial comum
- Nos outros 9 dispositivos DDR5, não houve bit flips, indicando a necessidade de pesquisa adicional para encontrar padrões mais eficazes para DDR5
- Todos os detalhes estarão no artigo a ser apresentado em agosto de 2024 na USENIX Security 2024
- O código do fuzzer ZenHammer está disponível no GitHub e pode ser usado para avaliar se dispositivos DRAM apresentam bit flips em CPUs AMD Zen 2/3/4
- Como Rowhammer é considerado um problema já conhecido em toda a indústria, os pesquisadores julgaram que não era necessário um processo de divulgação tradicional, mas notificaram a AMD em 26 de fevereiro de 2024 e, a pedido da empresa, não divulgaram até 25 de março de 2024
- Esta página ficou online por engano por um breve período em 21 de março de 2024
Limitações práticas no FAQ
- O motivo de sistemas AMD terem sido menos abordados anteriormente é que, nas pesquisas originais sobre Rowhammer, os sistemas Intel apresentavam muito mais bit flips, os estudos posteriores também se concentraram principalmente na Intel, e havia mais informações conhecidas publicamente sobre microarquiteturas de CPUs Intel do que AMD
- Embora não tenham ocorrido bit flips em 3 dos 10 dispositivos DDR4 no Zen 2 e em 4 no Zen 3, os pesquisadores consideram que, como esses dispositivos também apresentaram poucos bit flips no Intel Coffee Lake, ajustes adicionais no fuzzer podem acabar revelando bit flips
- O motivo de a avaliação ter sido limitada a 10 dispositivos é a quantidade restrita de equipamentos AMD Zen 2/3 no laboratório e o fato de alguns experimentos exigirem muito tempo; o subconjunto aleatório incluiu dispositivos dos 3 fornecedores de DRAM
- Sobre o motivo de a JEDEC ainda não ter resolvido o problema, os autores explicam que mitigar Rowhammer é difícil, mas não impossível, e que pesquisas anteriores como ProTRR e REGA já mostraram isso
- Pesquisas anteriores sobre DDR3 mostraram que ECC não impede Rowhammer, e como os atuais dispositivos DDR4 apresentam mais bit flips, o ECC é visto não como proteção completa, mas como algo que apenas dificulta a exploração
- Dobrar a taxa de refresh traz overhead de desempenho e aumento no consumo de energia e, em estudos anteriores como os de Mutlu et al. e Frigo et al., apareceu como uma solução fraca que não oferece proteção completa
1 comentários
Opiniões no Hacker News
Sou coautor do exploit Rowhammer original. ECC ainda é muito eficaz para transformar esse problema, em grande parte, de uma questão de segurança em uma questão de confiabilidade
Se você é dono de um servidor pessoal, e espera que o servidor tenha ECC e que você perceba uma parada da máquina causada por um erro ECC incorrigível, o impacto de segurança não é grande
Porém, se você é um provedor de nuvem que oferece VMs em um host multitenant, o modelo de ameaça pode ser diferente
De qualquer forma, máquinas sem ECC devem ser evitadas. TRR já era uma defesa fracassada quando Rowhammer ficou conhecido, e, enquanto a economia de fabricação de DRAM não mudar, bit flips em DRAM não vão desaparecer
O Ryzen só dá suporte a ECC unbuffered, que é mais lenta, mais cara, ou ambos, do que memória sem ECC da mesma capacidade
A linha Threadripper mais recente dá suporte a Registered ECC, mas, para um usuário doméstico como eu, custo, threads e lanes PCIe são todos excessivos
O risco de segurança é grande demais e tudo está integrado demais para adiar essa mudança. Até um gamer com um computador puramente para jogos provavelmente terá informações importantes nessa máquina; não entendo por que essa mudança ainda não aconteceu
Também me pergunto se só SRAM é realmente imune
Só Pro e Threadripper têm garantia, e alguns Ryzen desktop só funcionam em algumas placas-mãe
Quão agressivamente um mecanismo de patrol read precisaria varrer a DRAM para se antecipar com segurança aos bit flips induzidos por Rowhammer?
Com palavras ECC maiores do que o tradicional 64+8 e correção de erros multibit, isso muda o cenário o bastante para permitir sistemas mais confiáveis mesmo com DRAM suscetível a padrões?
Formulações como “ECC não impede Rowhammer” são muito enganosas. O artigo citado também diz que “mesmo quando a detecção por ECC é usada corretamente, 0,65% a 7,42% de todos os bit flips causam corrupção silenciosa… na configuração AMD-1, erros incorrigíveis derrubam o sistema”
Para obter um único bit flip explorável, o atacante precisaria causar dezenas de quedas da máquina. Dezenas de quedas de máquina não são algo que passe despercebido
É bom apontar que a resposta da JEDEC ao Rowhammer é péssima, mas, como solução de curto prazo, ECC não deve ser subestimado
É uma plataforma Zen2 TR, então meu coração quase parou quando vi essa frase. É uma formulação bastante enganosa
Fico curioso se problemas de segurança de hardware como Rowhammer, Spectre e Meltdown são riscos reais para pessoas comuns
Eu entendia que Spectre e Meltdown eram problemas para ataques como escape de VM, algo com que engenheiros da AWS deveriam se preocupar, não usuários individuais
E, já que você se desconectou da sociedade moderna, vá para uma cabana na floresta e viva de subsistência
Pessoalmente, gosto do NoScript. No Chrome, não sei bem o que escolher
Fora isso… você não costuma executar programas aleatórios da internet com frequência, certo?
Esse tipo de bug ainda está só arranhando a superfície. O hardware moderno é complexo demais para acreditar que conseguiremos encontrar todos
Por isso, todo mundo pode ser afetado
Eu entendia ataques de bit flip em DDR só de forma muito vaga, mas, ao olhar o artigo original Hammertime, vi que ele é realmente fácil de ler
Ainda não li tudo, mas ele explica muito bem, de um jeito fácil de entender. Eu tinha ouvido o termo bit flip inúmeras vezes, mas nunca tinha entendido de verdade; com isso, a ficha caiu
https://comsec.ethz.ch/wp-content/files/hammertime_raid18.pd...
Foi como assistir a uma aula introdutória de eletroeletrônica. Eu não fazia ideia de que isso tinha relação com defeitos de fabricação de hardware reais
O nome Rowhammer também só fez sentido então. Talvez eu estivesse muito por fora e isso seja algo que todo mundo já saiba
“Devido à densidade extrema dos arrays de DRAM modernos, pequenos defeitos de fabricação podem criar um acoplamento elétrico fraco entre células adjacentes. Combinado com a capacitância extremamente pequena dessas células, cada vez que uma linha de DRAM é lida em um banco, as células de memória das linhas adjacentes perdem uma pequena quantidade de carga. Se isso ocorrer com frequência suficiente entre dois ciclos de refresh, as células afetadas podem perder carga o bastante para que o valor do bit armazenado seja invertido, o que é chamado de ‘disturbance error’ ou, mais recentemente, Rowhammer”
É porque os fabricantes de DRAM levaram os limites ao extremo. É busca por lucro
Não é diferente da Ford ter concluído que o custo dos acordos em processos do Pinto envolvendo ferimentos e mortes seria menor que o custo de corrigir o projeto do veículo
Fico me perguntando se Secure Memory Encryption ajuda nisso
https://www.amd.com/en/developer/sev.html
Um único bit flip pode virar um erro fatal
Eu entendo muito pouco de segurança de hardware, então fico curioso se isso é uma daquelas muitas vulnerabilidades inevitáveis geradas por otimizações de CPU e que, na prática, têm baixa viabilidade
Acontece em um nível muito mais baixo do que casos de borda de funcionalidades que vazam informação por canais laterais
Os dados são armazenados como pequenas cargas em uma grade; se você alternar muitas vezes os pontos da grade próximos, consegue fazer parte da carga vazar na direção da carga-alvo
Quanto menores e mais próximas forem as cargas, mais fácil fica o ataque Rowhammer. Ao mesmo tempo, quanto menores e mais próximas forem as cargas, mais rápida, barata, densa e eficiente a RAM se torna
Existem mitigações, mas os limites já foram empurrados ao máximo
Fico me perguntando se isso funciona mesmo com criptografia total da memória, poisoning e XOR de endereços ativados
Então usar criptografia de memória é mais seguro
Se “o ZenHammer não conseguiu provocar flips em 9 de 10 dispositivos… são necessárias pesquisas adicionais para encontrar padrões mais eficazes em dispositivos DDR5”, então parece que a DDR5 ainda tem um pouco de tempo
Fico curioso se alguém sabe se isso também afeta LPDDR5x
Então a questão central não é se é DDR5, LPDDR5(x), GDDR6(x) ou HBM3(e)
O importante são detalhes de implementação que ficam a critério do fabricante, como ECC on-die
Zen 2 e 3 são mencionados, mas fico curioso se há informações sobre o Zen 1
Será que simplesmente se aplica do mesmo jeito?