Tavis Ormandy, pesquisador de segurança do Google, publicou detalhes sobre uma vulnerabilidade de hardware encontrada em CPUs AMD. A vulnerabilidade afeta as CPUs da série Zen 2 , apresentadas pela primeira vez em 2019. Mesmo sendo uma arquitetura obsoleta, ainda era usada em CPUs até o início de 2021. A linha inclui CPUs para computadores pessoais (como o popular Ryzen 5 3600), laptops , e — o mais importante — servidores (CPUs AMD EPYC “Rome”). Para obter uma lista completa das séries de CPU suscetíveis ao Zenbleed, consulte este artigo da Ars Technica .
A falha decorre de uma combinação de recursos bastante inofensivos da CPU AMD. Acontece que, se combinadas, uma certa interação com os registradores da CPU e um sistema perfeitamente normal de execução de código especulativo podem resultar em vazamento de dados secretos. Em teoria, é bastante fácil roubar informações usando essa vulnerabilidade (ID exclusivo CVE-2023-20593) e também em uma velocidade bastante alta: até 30 kBps para cada um dos núcleos da CPU. Até agora, nenhum caso real de exploração foi relatado. Por outro lado, patches (atualizações de microcódigo da CPU) estão disponíveis apenas para parte das CPUs afetadas. A AMD promete resolver o problema completamente até o final de 2023.
Detalhes de exploração do Zenbleed
Como foi mencionado anteriormente, o Zenbleed existe graças ao sistema de execução especulativa. A vulnerabilidade não é fácil de explicar. Em seu blogpost, Tavis Ormandy apresenta fatos frios que apenas um profissional experiente em codificação de baixo nível pode entender. Em poucas palavras, aqui está um dos conjuntos de instruções para a exploração do Zenbleed:
Uma descrição do GitHub pela equipe de segurança da informação do Google lança alguma luz sobre a natureza do problema. Nos últimos 15 anos, as CPUs Intel e AMD têm usado o conjunto de extensão de instrução AVX . Entre outras coisas, essas instruções suportam registradores vetoriais de 128 e 256 bits. Para simplificar, os registradores da CPU são usados para armazenamento temporário de dados durante a execução de instruções. Em alguns casos, ser capaz de armazenar grandes quantidades de dados em registradores vetoriais permite melhorar consideravelmente o desempenho. Os registradores de 128 bits (XMM) e 256 bits (YMM) são comumente usados para a maioria das operações de rotina, como as relacionadas à leitura/gravação de/para RAM.
O uso simultâneo de registradores de 128 e 256 bits traz outro conjunto de problemas. Se usados simultaneamente na mesma tarefa, os registradores XMM são automaticamente convertidos em registradores YMM. É aqui que a zeragem da “metade” superior do registrador YMM é realizada rotineiramente. A instrução especial para isso é vzeroupper . Todos os registradores são armazenados no chamado arquivo de registradores e são usados alternadamente por diferentes programas executados no computador.
O que há de comum entre Zenbleed e Use After Free?
Se você criar condições para que a instrução vzeroupper seja executada especulativamente , a operação terminará incorretamente nas CPUs AMD Zen 2. As CPUs podem executar instruções sem esperar pelos resultados dos cálculos anteriores com base na previsão de ramificação. Isso acelera muito o trabalho, mas também pode resultar em uma situação em que as instruções sejam executadas “em vão”, não sendo exigidas pela lógica do programa. Se isso acontecer, os resultados da execução da instrução devem ser revertidos. Assim, se vzeroupper for executado “em vão”, o zeramento de metade do registrador YMM deve ser cancelado.
É aqui que um erro de lógica entra em ação nas CPUs Zen 2. O registrador permanece no chamado estado “indefinido”. O que significa que ainda pode conter dados de outros programas que usam o arquivo de registro compartilhado. Em uma situação normal, nenhum ator deveria ter acesso a esses dados. O Zenbleed cria condições nas quais o malware pode “monitorar” as informações que passam pelos registros vetoriais.
De certa forma, esse comportamento da CPU se assemelha muito ao erro típico de software conhecido como use after free . É quando um programa usa uma determinada área de RAM para armazenar seus dados e, em seguida, desocupa essa área de RAM, tornando-a disponível para outros aplicativos. Como resultado, um terceiro programa pode ler esses dados, que podem conter informações secretas. No entanto, no caso do Zenbleed, não é um erro de software , mas de hardware .
Avaliação impactante
Em teoria, o Zenbleed permite ler segredos diretamente e faz isso em alta velocidade. Isso não significa muito por si só: coisas como quais dados podem ser lidos ou se podem ser usados de forma prejudicial, dependem de uma determinada situação. Somente aplicativos que usam XMM e YMM ao mesmo tempo são afetados por esta vulnerabilidade. Em primeiro lugar, essas são as bibliotecas do sistema Linux e o próprio kernel do Linux, bem como bibliotecas criptográficas e sistemas como o OpenSSL. Além disso, obter informações requer que o aplicativo seja intensivo em dados. Para que um invasor obtenha algo realmente útil, é necessário executar algum processo de criptografia no computador afetado ou usar ativamente o navegador para navegar na Web, caso contrário, a exploração da vulnerabilidade será em vão.
Foi-nos mostrado apenas o código de demonstração, a prova de conceito. Estava além do escopo do estudo demonstrar um cenário realmente prejudicial. De acordo com a equipe da Cloudflare , o problema é bastante fácil de explorar. Pode-se fazer isso até mesmo usando um navegador. Podemos imaginar um invasor enviando à vítima um link para uma página da Web pré-criada para roubar senhas de contas confidenciais do cache de memória. O mais triste é que um roubo desses não deixaria nem vestígios. Pode ser feito na vida real? Ainda não sabemos.
Mas sabemos que o Zenbleed é mais perigoso em um ambiente corporativo. Imagine uma situação em que um locatário de servidor virtual pode ler dados de outros servidores e até mesmo do hipervisor, desde que usem os mesmos núcleos de CPU. É por isso que o primeiro patch a ser lançado abordava as CPUs do servidor AMD EPYC.
Futuro da segurança de hardware
Na parte final de seu artigo, Tavis Ormandy revela que descobriu o problema graças ao fuzzing. Aplicado ao teste de software, fuzzing normalmente significa “alimentar” o programa com dados aleatórios em busca de uma situação em que um conjunto específico de tais dados cause algum comportamento anormal. Aqui temos um desafio mais sofisticado: hardware fuzzing (vamos chamá-lo assim) implica criar programas empregando um conjunto aleatório de instruções em busca de uma resposta anormal da CPU. Um encerramento anormal de tal programa não é necessariamente um sinal de problema como tal. Ormandy propõe vários métodos para detecção de anomalias, como executar o mesmo código em CPUs diferentes — se programas idênticos demonstrarem comportamento diferente, ele solicitará uma investigação para garantir que nenhum erro de lógica da CPU esteja envolvido.
O histórico de vulnerabilidades de hardware sugere que geralmente não basta resolver um problema sozinho. Após a aplicação do patch, uma nova forma de burlar o novo sistema de defesa pode ser encontrada, pois o problema está nos princípios fundamentais de funcionamento da CPU. É por isso que Tavis Ormandy não apenas encontrou uma vulnerabilidade de CPU AMD Zen 2, mas também propôs algumas estratégias interessantes sobre como localizar outros possíveis erros.
Por mais perigoso que seja, o Zenbleed provavelmente não será usado para atacar usuários individuais. Mas a infraestrutura de servidor das organizações é uma história diferente. Nesse caso específico, você pode dizer que foi uma fuga por pouco: o problema foi encontrado e corrigido com uma atualização de microcódigo, com apenas uma pequena queda de desempenho. Se sua infraestrutura usa CPUs AMD Zen 2, você também precisa deste patch. Mas é provável que esta pesquisa seja seguida por outras. Toda a atitude em relação à segurança de hardware pode ser revisada, com novos testes de segurança abrangentes (empregando fuzzing e outras estratégias) entrando em cena. Vamos esperar que os fornecedores de hardware possam usá-los com uma boa vantagem. Mas as organizações ainda precisam integrar o risco representado por vulnerabilidades semelhantes emergentes em seus modelos de segurança.
