A AMD corrigiu uma vulnerabilidade considerada grave em seu software de atualização automática de drivers, mas a solução veio acompanhada de uma polêmica envolvendo o pesquisador responsável pela descoberta da falha. Conhecido como Paul, o especialista em segurança revelou que a empresa recusou o pagamento de uma recompensa estimada em US$ 10 mil, mesmo após solicitar vários meses de sigilo para corrigir o problema antes da divulgação pública.
Segundo o relato publicado pelo pesquisador, a vulnerabilidade poderia permitir a execução remota de código em determinadas circunstâncias, abrindo caminho para ataques capazes de comprometer sistemas de usuários. Apesar da gravidade potencial da descoberta, a AMD argumentou que o tipo específico de ataque necessário para explorar a falha não está contemplado pelas regras de seu programa oficial de recompensas.
Falha envolvia ataque do tipo man-in-the-middle
De acordo com Paul, o problema estava relacionado ao mecanismo utilizado pelo software da AMD para baixar atualizações de drivers. Um invasor posicionado entre o computador da vítima e o servidor de atualização poderia, teoricamente, interceptar a comunicação e modificar os arquivos transferidos, criando condições para a execução de código malicioso.
Esse tipo de ataque é conhecido como man-in-the-middle, ou MITM, e figura entre as técnicas mais conhecidas da área de segurança digital. Embora sua exploração prática dependa de condições específicas, o potencial impacto costuma ser elevado, especialmente quando envolve softwares responsáveis por instalar atualizações de sistema.
O que é um ataque man-in-the-middle (MITM)?
Um ataque man-in-the-middle ocorre quando um invasor consegue se posicionar entre duas partes que estão se comunicando, interceptando ou alterando informações transmitidas sem que os envolvidos percebam.
Na prática, o criminoso pode monitorar dados, capturar credenciais ou até modificar arquivos transferidos durante uma atualização de software. Por isso, conexões protegidas por HTTPS e certificados digitais são consideradas fundamentais para reduzir esse tipo de risco.
AMD pediu sigilo por mais de quatro meses
O pesquisador afirma que notificou a AMD sobre a vulnerabilidade antes de fevereiro deste ano. Inicialmente, ele sugeriu seguir a prática comum da indústria, que costuma adotar um período de aproximadamente 90 dias entre a descoberta da falha e sua divulgação pública. No entanto, a fabricante solicitou um prazo maior para concluir a correção.
Segundo Paul, a empresa alegou que a vulnerabilidade afetava não apenas o Ryzen Master, mas também outras ferramentas distribuídas pela AMD. Como consequência, o embargo acabou sendo ampliado para 100 dias e, posteriormente, estendido novamente devido à necessidade de preparar correções para múltiplos produtos.
No final, a solução definitiva só foi disponibilizada em 9 de junho, totalizando cerca de 124 dias entre a descoberta inicial e a liberação do patch de segurança.
Programa de recompensas gerou controvérsia
Apesar da colaboração durante o processo de correção, a AMD recusou o pagamento da recompensa financeira. A justificativa apresentada foi que vulnerabilidades dependentes de ataques man-in-the-middle não fazem parte do escopo coberto pelo programa de bug bounty da companhia.
Mesmo assim, a fabricante solicitou que o pesquisador removesse temporariamente informações públicas sobre a falha até que o problema fosse corrigido. Em troca, a empresa concordou em emitir um identificador CVE oficial para a vulnerabilidade e creditar Paul pela descoberta.
O que é um programa de bug bounty?
Bug bounty é um programa criado por empresas para recompensar pesquisadores de segurança que identificam falhas em seus produtos. Dependendo da gravidade da vulnerabilidade, os pagamentos podem variar de algumas centenas até centenas de milhares de dólares.
Esses programas incentivam a divulgação responsável de problemas de segurança e ajudam fabricantes a corrigir falhas antes que elas sejam exploradas por criminosos.
Correção trouxe mudanças na forma de baixar drivers
Com a atualização liberada em junho, a AMD modificou o funcionamento do sistema responsável pelo download de drivers e reorganizou partes importantes do código. O objetivo foi aumentar a segurança do processo e reduzir as possibilidades de manipulação dos arquivos transferidos durante as atualizações.
No entanto, Paul observou que alguns aspectos ainda podem ser aprimorados. Segundo ele, o software continua utilizando verificações baseadas em CRC32 para validar determinados arquivos, uma técnica considerada insuficiente para aplicações modernas de segurança devido às limitações criptográficas desse método.
O que é CRC32?
CRC32 é um algoritmo utilizado para verificar a integridade de arquivos e detectar erros de transmissão ou armazenamento. Ele é eficiente para identificar corrupções acidentais de dados, mas não foi projetado para oferecer proteção contra ataques maliciosos.
Por esse motivo, sistemas modernos de segurança costumam utilizar algoritmos criptográficos mais robustos, como SHA-256, capazes de dificultar tentativas de adulteração intencional de arquivos.
Falha talvez nem pudesse ser explorada na prática
Para tornar a situação ainda mais curiosa, um usuário do Reddit analisou os detalhes técnicos divulgados após a correção e apontou que a parte vulnerável do código aparentemente não estava sendo chamada pelo sistema durante o processo normal de atualização. Caso essa análise esteja correta, a falha poderia ser teoricamente perigosa, mas praticamente impossível de explorar.
A hipótese levantada sugere ainda que o próprio mecanismo automático de atualização poderia não estar funcionando corretamente, exigindo intervenções manuais para instalação de novos drivers. Até o momento, a AMD não comentou publicamente essa interpretação.
Segurança continua sendo desafio para grandes fabricantes
Independentemente da possibilidade real de exploração, o episódio reforça a importância da colaboração entre pesquisadores independentes e fabricantes de hardware. A descoberta permitiu que a AMD revisasse parte de sua infraestrutura de atualização e corrigisse potenciais fragilidades antes que elas se tornassem um problema maior.
Ao mesmo tempo, a discussão sobre programas de recompensa permanece em evidência. Casos como este mostram que nem sempre existe consenso entre pesquisadores e empresas sobre quais vulnerabilidades merecem compensação financeira, especialmente quando envolvem cenários de ataque considerados improváveis ou fora do escopo previamente definido.