.
A AMD começou a emitir alguns patches para seus processadores afetados por um grave bug no nível do silício chamado Zenbleed, que pode ser explorado por usuários desonestos e malware para roubar senhas, chaves criptográficas e outros segredos de software executado em um sistema vulnerável.
O Zenbleed afeta os chips Ryzen e Epyc Zen 2 e pode ser abusado para passar informações a uma taxa de pelo menos 30Kb por núcleo por segundo. Isso é prático o suficiente para alguém em um servidor compartilhado, como uma caixa hospedada na nuvem, espionar outros inquilinos. Explorar o Zenbleed envolve abusar da execução especulativa, embora ao contrário do relacionado Espectro família de falhas de design, o bug é muito fácil de explorar. Está mais de acordo com Derretimento.
O malware já em execução em um sistema, ou um usuário logado não autorizado, pode explorar o Zenbleed sem nenhum privilégio especial e inspecionar os dados à medida que são processados por aplicativos e pelo sistema operacional, que podem incluir segredos confidenciais, como senhas. Entende-se que uma página da Web maliciosa, executando um JavaScript cuidadosamente elaborado, pode explorar silenciosamente o Zenbleed em um computador pessoal para bisbilhotar essas informações.
A vulnerabilidade foi destacada hoje pelo guru da segurança de informações do Google, Tavis Ormandy, que descobriu a vulnerabilidade de vazamento de dados enquanto vasculhava o hardware em busca de falhas e a relatou à AMD em maio. Ormandy, que agradeceu a ajuda de alguns de seus colegas na investigação da falha de segurança, disse que a AMD pretende resolver a falha com atualizações de microcódigo e instado os usuários “atualizem” suas máquinas vulneráveis assim que puderem.
O código de exploração de prova de conceito, produzido pela Ormandy, está disponível aqui, e confirmamos que ele funciona em um sistema de servidor Zen 2 Epyc quando executado no bare metal. Enquanto a exploração é executada, ela mostra todos os dados confidenciais processados pela caixa. Se você colocar qualquer camada de emulação no meio, como Qemu, a exploração falhará compreensivelmente.
O que foi atingido?
O bug afeta todos os processadores AMD Zen 2, incluindo as seguintes séries: Ryzen 3000; Ryzen Pro 3000; Ryzen Threadripper 3000; Ryzen 4000 Pro; Ryzen 4000, 5000 e 7020 com Radeon Graphics; e processadores de datacenter Epyc Rome.
A AMD emitiu hoje um aviso de segurança aqui, usando os identificadores AMD-SB-7008 e CVE-2023-20593 para rastrear a vulnerabilidade. A gigante dos chips classificou a falha como de gravidade média, descrevendo-a como um “vazamento de informações entre processos”.
Um patch de microcódigo para processadores Epyc 7002 já está disponível. Quanto ao restante do silício afetado: a AMD tem como alvo dezembro de 2023 para atualizações para sistemas de desktop (por exemplo, Ryzen 3000 e Ryzen 4000 com Radeon); Outubro para desktops de última geração (por exemplo, Threadripper 3000); novembro e dezembro para estações de trabalho (por exemplo, Threadripper Pro 3000); e de novembro a dezembro para Ryzens móveis (lapto-grade). Sistemas compartilhados são a prioridade, ao que parece, o que faz sentido dada a natureza do erro de design.
Ormandy observou que pelo menos algumas atualizações de microcódigo da AMD estão fazendo o seu caminho no núcleo do Linux. OpenBSD tem alguns detalhes aqui. Nosso conselho é ficar atento às atualizações do microcódigo Zenbleed da AMD e a quaisquer atualizações de segurança para seu sistema operacional e aplicá-las conforme necessário, quando disponíveis. Ainda não se sabe se haverá um impacto no desempenho com a instalação, mas podemos imaginar que isso dependerá principalmente de suas cargas de trabalho.
Há uma solução entretanto, que Ormandy estabeleceu em sua descrição do bug (cópia arquivada já que seu site estava sendo bombardeado com tráfego anteriormente). Isso envolve a configuração de um bit de controle que desativa algumas funcionalidades que impedem a exploração. Imaginamos que isso diminui parte da execução especulativa necessária para explorar o Zenbleed, e isso pode causar algum tipo de impacto no desempenho.
Como o bug funciona?
Para obter os detalhes técnicos completos, consulte o artigo acima. Mas vamos resumir aqui; a compreensão de como os núcleos da CPU funcionam no nível do código de máquina é útil aqui.
Como uma família moderna de processadores x86, os chips Zen 2 da AMD oferecem registradores vetoriais, um monte de registradores longos para realizar operações. Esses registradores vetoriais são usados por aplicativos e sistemas operacionais para fazer todos os tipos de coisas, como operações matemáticas e processamento de strings. Como tal, esses registradores têm todos os tipos de dados passando por eles, incluindo senhas e chaves.
Existe uma instrução chamada vzeroupper [AMD PDF, page 860] que zera alguns desses registradores vetoriais e é usado em rotinas de sistema operacional e biblioteca de aplicativos que são chamadas centenas ou milhares de vezes por segundo por todos os núcleos do processador em uma caixa. Por exemplo, o strlen() função usa vzerouppere isso é chamado bastante.
Quando os chips da AMD são executados vzeroupper, eles simplesmente marcam os registros afetados como zero, definindo um bit especial e, em seguida, permitem que esses registros sejam usados para outras operações. Se vzeroupper é executado especulativamente – o processador antecipa que precisará executar essa instrução – ele define esse bit zero e libera os registradores no arquivo de registradores para reutilização. Isso pode acontecer se o vzeroupper a instrução fica logo após uma instrução de desvio; se o processador achar que é improvável que o desvio seja feito, ele iniciará o vzeroupper especulativamente. Como vimos com Spectre e Meltdown, as CPUs fazem esse tipo de coisa para obter grandes aumentos de desempenho.
Se o núcleo do processador perceber logo depois, na verdade, não deveria ter executado especulativamente o vzeroupper instrução, ele tenta retroceder aquela decisão e desfazer o zeramento limpando o bit que indica que os registradores estão zerados. Infelizmente, a essa altura, os registradores provavelmente estão em uso por algum outro código e não estão mais marcados como zero, portanto, seu conteúdo da operação anterior agora está acessível a esse outro código.
É por isso que a falha está sendo comparada a uma vulnerabilidade do estilo use-after-free().
Com os threads sendo agendados em todo o complexo do núcleo do processador e com algum código de exploração inteligente, é possível causar vzeroupper sejam incorretamente executados especulativamente, rebobinados e os dados vazem observando o conteúdo desses registros vetoriais. Baseia-se na execução especulativa de vzeroupper e o fato de que os registradores são armazenados em um grande arquivo de registradores e reatribuídos às operações conforme necessário.
Como observou Ormandy, “bits e bytes estão fluindo para esses registros vetoriais de todo o seu sistema constantemente”. Ele continuou:
Sua conclusão: “Acontece que o gerenciamento de memória é difícil, mesmo em silício”.
Pedimos à AMD mais comentários. ®
.
