Em uma declaração ao WIRED, a AMD enfatizou a dificuldade de explorar o Sinkclose: Para aproveitar a vulnerabilidade, um hacker já deve possuir acesso ao kernel de um computador, o núcleo do sistema operacional. A AMD compara a técnica Sinkhole a um método de acessar as caixas de depósito do banco após já ter burlado seus alarmes, guardas e porta do cofre.
Nissim e Okupski afirmam que, embora explorar o Sinkclose exija acesso ao nível do kernel de uma máquina, tais vulnerabilidades são expostas no Windows e no Linux praticamente todos os meses. Eles argumentam que hackers sofisticados financiados por estados, do tipo que podem tirar proveito do Sinkclose, provavelmente já possuem técnicas para explorar essas vulnerabilidades, conhecidas ou não. “As pessoas têm exploits de kernel agora mesmo para todos esses sistemas”, diz Nissim. “Eles existem e estão disponíveis para os atacantes. Este é o próximo passo.”
A técnica Sinkclose de Nissim e Okupski funciona explorando um recurso obscuro de chips da AMD conhecido como TClose (Fecho do Tipo T). Em máquinas baseadas na AMD, um mecanismo conhecido como TSeg impede que os sistemas operacionais dos computadores escrevam em uma parte protegida da memória destinada a ser reservada para o Modo de Gerenciamento do Sistema conhecido como Memória Aleatória de Acesso do Modo de Gerenciamento do Sistema ou SMRAM. O recurso TClose da AMD, no entanto, é projetado para permitir que os computadores permaneçam compatíveis com dispositivos mais antigos que usam os mesmos endereços de memória que o SMRAM, remapeando outra memória para esses endereços de SMRAM quando é habilitado. Nissim e Okupski descobriram que, apenas com o nível de privilégios do sistema operacional, poderiam usar esse recurso de remapeamento do TClose para enganar o código SMM para buscar dados que eles manipularam, de uma maneira que lhes permite redirecionar o processador e fazê-lo executar seu próprio código no mesmo nível SMM altamente privilegiado.
“Acho que é o bug mais complexo que já exploitei”, diz Okupski.
Nissim e Okupski, especialistas em segurança de código de baixo nível como o firmware do processador, afirmam que decidiram investigar a arquitetura da AMD dois anos atrás, simplesmente porque sentiam que não havia recebido a atenção necessária em comparação com a Intel, mesmo com a participação de mercado aumentando. Eles encontraram o crucial caso de borda do TClose que permitiu o Sinkclose, dizem eles, apenas lendo e relendo a documentação da AMD. “Acho que li a página onde estava a vulnerabilidade cerca de mil vezes”, diz Nissim. “E então na mil e primeira vez, eu notei.” Eles alertaram a AMD para a falha em outubro do ano passado, dizem eles, mas esperaram quase 10 meses para dar à AMD mais tempo para preparar uma correção.
Para usuários que buscam se proteger, Nissim e Okupski dizem que, para máquinas com Windows – provavelmente a maioria dos sistemas afetados – eles esperam que as correções para o Sinkclose sejam integradas às atualizações compartilhadas pelos fabricantes de computadores com a Microsoft, que as incluirão em futuras atualizações do sistema operacional. Correções para servidores, sistemas embarcados e máquinas Linux podem ser mais fragmentadas e manuais; para máquinas Linux, dependerá em parte da distribuição do Linux que um computador tem instalada.
Nissim e Okupski dizem que concordaram com a AMD em não publicar nenhum código de prova de conceito para seu exploit Sinkclose por vários meses, a fim de dar mais tempo para o problema ser corrigido. Mas eles argumentam que, apesar de qualquer tentativa da AMD ou de outros de minimizar o Sinkclose como muito difícil de explorar, isso não deve impedir os usuários de fazer a atualização o mais rápido possível. Hackers sofisticados podem já ter descoberto a técnica deles – ou podem descobrir como fazer isso depois que Nissim e Okupski apresentarem suas descobertas na Defcon.
Mesmo que o Sinkclose exija um acesso relativamente profundo, os pesquisadores da IOActive alertam que o nível muito mais profundo de controle que ele oferece significa que os possíveis alvos não devem esperar para implementar qualquer correção disponível. “Se a base está comprometida”, diz Nissim, “então a segurança de todo o sistema está comprometida.”
