AMD leva quatro meses para corrigir falha de MITM em atualizador de drivers
A AMD levou cerca de quatro meses para corrigir uma vulnerabilidade grave em seu atualizador de drivers, que permitia ataques de homem-no-meio (MITM) durante o processo de download de arquivos. O problema estava no uso do protocolo HTTP, sem criptografia, abrindo espaço para que um invasor interceptasse e alterasse o conteúdo baixado pelos usuários.
A falha foi identificada por um programador neozelandês, que se apresenta com o pseudônimo de MrBruh. Em 6 de fevereiro, ele submeteu o relatório de vulnerabilidade à plataforma de bug bounty utilizada pela AMD. A resposta foi imediata, mas desanimadora: a plataforma informou que ataques MITM não estavam cobertos pelo programa de recompensas, encerrando o caso ali mesmo, sem qualquer incentivo financeiro ou aprofundamento público.
De acordo com o pesquisador, o cenário era especialmente perigoso porque qualquer atacante posicionado na mesma rede da vítima – por exemplo, em um Wi-Fi público – ou com acesso à infraestrutura do provedor de internet poderia manipular o tráfego. Como o atualizador da AMD realizava o download por HTTP, sem uso de TLS/HTTPS, o conteúdo trafegava em texto claro. Isso permitiria substituir o pacote legítimo por um arquivo malicioso, como um instalador contendo malware, sem que o usuário percebesse.
A situação só ganhou tração quando o pesquisador decidiu publicar um artigo em seu blog detalhando o problema. A publicação repercutiu fortemente em fóruns técnicos e entre especialistas em segurança, chamando atenção para o risco a milhões de usuários que dependem do software de atualização da AMD para manter drivers de vídeo e chipset em dia.
Após a viralização do post, a AMD entrou em contato no dia seguinte afirmando que estava investigando a vulnerabilidade. A empresa também pediu ao pesquisador que removesse o texto do ar, alegando que isso ajudaria a mitigar possíveis riscos até que uma correção fosse disponibilizada. Ele atendeu ao pedido e tirou o artigo do ar, mas, olhando em retrospecto, afirma que essa foi uma decisão equivocada, já que a ausência de transparência permitiu um período prolongado de exposição sem a devida pressão pública por uma solução rápida.
A AMD comunicou ao pesquisador que não haveria qualquer recompensa financeira pelo achado, mantendo a posição inicial da plataforma de bug bounty: ataques MITM não estariam contemplados na política de pagamento de vulnerabilidades. Em contrapartida, a empresa prometeu desenvolver uma atualização de segurança, além de creditar o pesquisador pelo reporte assim que tudo estivesse resolvido.
Parte da resposta oficial da fabricante foi a afirmação de que, doravante, as atualizações passariam a ter suas assinaturas digitais verificadas pelo software de atualização. Na prática, isso significaria um salto de segurança: mesmo que um atacante conseguisse interferir no tráfego de rede, a assinatura criptográfica garantiria a integridade e autenticidade do arquivo baixado.
No entanto, segundo MrBruh, a implementação apresentada pela AMD não corresponde à promessa. Em vez de uma verificação criptográfica robusta, como o uso de assinaturas digitais com chaves públicas ou algoritmos de hash seguros, o atualizador estaria utilizando apenas uma verificação baseada em CRC-32. Esse tipo de checagem é adequado para detectar erros acidentais de transmissão, mas é totalmente insuficiente contra ataques deliberados. Um atacante com conhecimento técnico pode facilmente gerar um arquivo malicioso que passe nesse tipo de validação.
O ponto central da crítica do pesquisador é que simplesmente migrar o download de HTTP para HTTPS, sem uma verificação criptográfica forte no pacote, não resolve completamente o problema de segurança da cadeia de atualização. Embora HTTPS reduza drasticamente o risco de ataques MITM, ele não é uma barreira absoluta em cenários de comprometimento de infraestrutura, certificados ou em ambientes com inspeção TLS mal configurada. A ausência de assinatura digital real torna o sistema dependente demais da camada de transporte.
Esse caso expõe uma fragilidade recorrente em soluções de atualização de software: muitos fabricantes ainda tratam o atualizador como algo secundário, quando, na prática, ele é um dos componentes mais sensíveis de todo o ecossistema. Quem controla o fluxo de atualização controla, em grande medida, o dispositivo. Por isso, a combinação de HTTPS com assinaturas digitais fortes, verificação independente de integridade e, idealmente, transparência de atualizações deveria ser padrão em qualquer grande fornecedora de hardware ou software.
A postura da AMD em relação ao programa de bug bounty também entra em debate. Ao excluir ataques MITM da política de recompensas, a empresa desestimula pesquisadores a reportarem problemas justamente em uma das áreas mais críticas: a segurança da comunicação e da infraestrutura de distribuição de software. Em muitos casos, vulnerabilidades desse tipo são complexas, exigem testes cuidadosos e impactam milhões de usuários, o que justificaria um tratamento mais sério e, sim, recompensas condizentes.
Outro aspecto sensível é o pedido para retirada do conteúdo publicado pelo pesquisador. Esse tipo de solicitação é comum quando ainda não há correção disponível, mas precisa ser equilibrado com o direito à informação e com a responsabilidade da empresa em agir rapidamente. Sem prazos claros, comunicados públicos e transparência sobre o progresso da correção, o que se instala é um período cinzento em que os usuários seguem expostos sem sequer saber disso.
Do ponto de vista técnico, o caso reforça algumas boas práticas essenciais para qualquer sistema de atualização de software:
1. Uso obrigatório de HTTPS/TLS – Todo tráfego de download de pacotes deve ser criptografado, com configurações modernas de TLS, proteção contra downgrade e verificação rigorosa de certificados.
2. Assinaturas digitais fortes – Pacotes devem ser assinados com chaves privadas protegidas e verificados no cliente com chaves públicas embutidas no software. Assim, um atacante não consegue simplesmente trocar o arquivo por outro.
3. Hashes criptográficos confiáveis – Algoritmos como SHA-256 ou superiores devem ser utilizados para garantir a integridade dos arquivos. Tarefas de verificação não podem se apoiar apenas em CRC ou checksums simples.
4. Defesa em profundidade – A segurança não pode depender de um único mecanismo. Mesmo que HTTPS esteja corretamente configurado, a assinatura do pacote é uma camada adicional essencial.
5. Atualizações automáticas, porém seguras – Automatizar a atualização aumenta a segurança ao reduzir janelas de exposição, mas só se o pipeline for projetado desde o início com foco em integridade e autenticação de ponta a ponta.
No campo da gestão de risco, o atraso de quatro meses para tratar uma vulnerabilidade com potencial de distribuição de malware em massa é particularmente preocupante. Em ambientes corporativos, onde equipamentos com GPUs AMD são utilizados para renderização, jogos, estações de trabalho ou até cargas de trabalho críticas, um comprometimento da cadeia de atualização poderia abrir portas para ransomwares, backdoors persistentes e furto de dados confidenciais.
Para usuários finais e empresas, o episódio reforça algumas recomendações práticas:
– Monitorar atualizações de segurança e notas de versão dos fabricantes de hardware.
– Priorizar o download de drivers e firmwares diretamente de painéis oficiais e, quando possível, optar por canais autenticados do sistema operacional.
– Implementar camadas adicionais de proteção na rede, como filtragem de tráfego suspeito e inspeção de comportamento em endpoints.
– Avaliar políticas de bug bounty e transparência das empresas na hora de escolher fornecedores de tecnologia, especialmente em ambientes críticos.
Por fim, o caso AMD ilustra um dilema mais amplo na indústria de tecnologia: a distância entre o discurso de segurança e a prática concreta. Empresas frequentemente destacam investimentos em cibersegurança, mas ainda falham em fundamentos básicos, como proteger corretamente os mecanismos de atualização. Ao mesmo tempo, a relação com pesquisadores independentes segue marcada por tensões, pedidos de silêncio e, em muitos casos, ausência de reconhecimento financeiro proporcional ao impacto da vulnerabilidade descoberta.
A correção da falha e a adoção de HTTPS representam um avanço, mas a crítica do pesquisador sobre o uso de CRC-32 mostra que ainda há um caminho a percorrer para que o processo de atualização da AMD atinja o nível de segurança esperado para um fornecedor global de componentes de hardware. O episódio serve como alerta não apenas para a própria empresa, mas para toda a indústria: a segurança da cadeia de atualização não é um detalhe técnico, é um dos pilares da confiança digital.