Vulnerabilidade de execução remota de código (RCE) que a AMD decidiu não corrigir

• Foi descoberta e reportada uma vulnerabilidade de execução remota de código (RCE) no software AutoUpdate da AMD, mas a AMD decidiu não corrigi-la
• A URL armazenada no arquivo de configuração de atualização usa o protocolo HTTP para baixar executáveis, o que a torna vulnerável a MITM (ataque man-in-the-middle)
• O software foi projetado para executar imediatamente o arquivo baixado sem verificar a assinatura
• A AMD classificou o problema como “fora do escopo (out of scope)” e não o reconheceu como vulnerabilidade de segurança
• Apesar do risco de um invasor de rede conseguir distribuir executáveis maliciosos, a ausência de patch é apontada como uma preocupação de segurança

---

Como a vulnerabilidade de RCE no AMD AutoUpdate foi descoberta

• Ao investigar um problema de janela de console que aparecia periodicamente em um novo PC gamer, foi confirmado que a causa era o executável AMD AutoUpdate
• No processo de descompilar o programa, a vulnerabilidade de RCE foi descoberta por acaso
• A URL de atualização está armazenada no arquivo app.config e, mesmo em produção, está sendo usada uma URL de Development
• Essa URL usa HTTPS, mas os links reais para download dos executáveis estão em HTTP

Problemas técnicos da vulnerabilidade

• Como os executáveis são baixados via HTTP, um invasor na rede ou até no nível do ISP pode manipular a resposta e substituí-los por arquivos maliciosos
• O programa AutoUpdate não realiza validação de certificado nem de assinatura dos arquivos baixados
• Como resultado, o invasor pode distribuir qualquer executável, e o programa pode executá-lo imediatamente

Resposta da AMD e resultado do reporte

• Após a descoberta, a vulnerabilidade foi reportada à AMD, mas o caso foi encerrado como “won’t fix” e “fora do escopo (out of scope)”
• A AMD não considera essa vulnerabilidade um problema de segurança
• O cronograma de reporte e divulgação foi o seguinte
  • 27/01/2026: vulnerabilidade descoberta
  • 05/02/2026: reportada à AMD
  • 05/02/2026: encerrada como “won’t fix/out of scope”
  • 06/02/2026: publicação no blog

Implicações de segurança

• Uma estrutura de atualização baseada em HTTP e a ausência de verificação de assinatura podem expor o sistema do usuário a ataques de execução remota de código
• A decisão da AMD de não corrigir o problema pode gerar controvérsia na comunidade de segurança
• Se houver um invasor na rede, existe o risco de exploração como canal de distribuição de malware

[GN⁺]

Comentários do Hacker News

• Um bom motivo para o Linux incluir todos os drivers é que isso evita a necessidade de instalar software de gerenciamento de drivers de baixa qualidade ou até com spyware
  Esses programas são difíceis de colocar em sandbox e representam riscos de segurança
  Curiosamente, parece que os mantenedores de distribuições, trabalhando de graça, são muito mais competentes em segurança do que fabricantes de hardware avaliados em bilhões de dólares

  • Não é que os fabricantes de hardware sejam incompetentes em segurança, só têm prioridades diferentes
    Mantenedores de distribuições valorizam a segurança, enquanto os vendors se preocupam mais em lançar rápido a próxima geração de hardware
    No fim, os dois grupos têm objetivos diferentes
  • Acho que essa qualidade se mantém por causa da organização criada pelo Linus e dos incontáveis contribuidores que participam dela
    Um pequeno número de pessoas influentes está fazendo silenciosamente um ótimo trabalho
    Vejo isso como sinal de que quem não aparece nas notícias é quem realmente manda bem
  • Ryzen Master não é um driver
    A maior parte dos recursos dele não está disponível no Linux
  • Não está claro se o problema do post original é uma questão relacionada ao Windows
  • Hoje em dia os vendors estão migrando para um modelo em que sobem um servidor web local e controlam o hardware pelo navegador, o que parece uma ideia horrível do ponto de vista de segurança

• Eu bloqueio todo o tráfego HTTP
  Não só a AMD, mas Gigabyte, ASUS e outras também falham na atualização automática se não houver acesso via HTTP
  Esta thread no Reddit também trata desse problema
  Requisições HTTP sem criptografia representam vazamento de privacidade e um potencial vetor de ataque MitM
  Uma stack TLS é um alvo muito mais difícil de atacar

  • Se o payload for assinado, o nível de confiança é parecido com HTTP ou HTTPS
    No fim, você está confiando no código de verificação de assinatura do cliente, o que não é tão diferente de confiar no GPG
  • Mas isso não quebra as consultas a CRL ou OCSP?
  • Muitos repositórios de pacotes Linux ainda usam só HTTP
    É conveniente para rastrear as versões dos pacotes instalados, mas inseguro do ponto de vista de segurança

• Isso é um problema realmente sério
  É uma situação em que um redirecionamento HTTP permite execução arbitrária de código, e um programa desses está instalado em inúmeros PCs
  Bastaria abrir um hotspot de Wi‑Fi em um aeroporto para atacar imediatamente usuários de placas ATI

  • No meu país, fazer isso daria prisão
    Então, no fim, a única prevenção é a lei
  • Claro que é ruim, mas isso só funciona quando há atualização disponível
    Ou seja, só se aplica quando você se conecta sem VPN a um hotspot arriscado, a AMD publicou recentemente uma atualização e o agendador é executado
  • Quem se conectaria ao hotspot de um desconhecido?
    Mas, se o ISP local for malicioso, o ataque fica muito mais fácil
  • Eu uso com atualização automática desativada
    Desde a era do Win98 acho atualização automática o recurso mais idiota que existe

• Basta envenenar o DNS uma única vez para o ataque ser possível
  Por exemplo, se o roteador for comprometido e devolver um IP incorreto, dá para injetar um binário malicioso no tráfego HTTP
  HTTPS passa intacto, mas HTTP é vulnerável
  Quem ainda usa a senha padrão de administrador deve trocá-la agora mesmo
  Um atacante também pode fazer a mesma coisa com spoofing de DHCP ou Wi‑Fi falso

  • É muito fácil levar usuários a se conectarem a um Wi‑Fi malicioso usando spoofing de SSID ou jamming de sinal
  • Só de responder ao DNS primeiro já é possível atacar

• É difícil entender por que a AMD rejeitou isso por estar fora do escopo do bug bounty
  Perder um único cliente já custaria mais do que a recompensa, então usar o escopo do documento como desculpa para ignorar segurança passa um péssimo sinal
  Essa postura fará com que hackers deixem de reportar problemas à AMD no futuro

  • Na verdade, a AMD já foi alertada sobre esse problema várias vezes
    Então, mesmo que estivesse dentro do escopo, seria estranho receber recompensa por isso

• Isso não é um simples erro, e sim uma falha no processo de reporte de segurança
  Está no nível de departamentos de segurança de grandes empresas discutirem proibir hardware AMD ou o app de atualização da AMD
  Se tivesse sido registrado como CVE, seria um caso grande o bastante para sair nas notícias
  Um atacante poderia monitorar tráfego HTTP em Wi‑Fi público ou em um ISP e infectar executáveis

  • Qualquer pessoa pode solicitar um CVE, então esse pode acabar sendo o único caminho para forçar uma correção

• A AMD não disse que isso não era uma vulnerabilidade, apenas que estava fora do escopo do bug bounty

  • Mas ignorar uma vulnerabilidade que permite elevação de privilégio remota é injustificável
    Para um atacante não existe esse conceito de “fora do escopo”, mas a AMD o adotou como política
    Isso é uma clara política de irresponsabilidade em segurança
  • A ponto de se dizer que, no fim, o próprio documento de escopo da AMD é o bug

• Esta é uma vulnerabilidade muito séria
  Não deveria ser minimizada pelo argumento de que “exige MitM”
  A própria internet já é um ambiente MitM

  • Na prática, nem MitM é necessário
    Um servidor DHCP malicioso já pode manipular o DNS e viabilizar o ataque

• A AMD ter encerrado o caso em um dia como “out of scope / won't fix” foi precipitado demais
  Isso pode significar apenas que o caso não pertence ao canal de bug bounty, não necessariamente que não será corrigido de fato

• No meu PC, o terminal do AMD AutoUpdate aparece todo dia à meia-noite e eu tenho que fechá-lo
  Agora tenho um motivo para bloquear isso de vez e voltar às atualizações manuais

  • Ah, então era aquela janela! Eu estava há dias tentando descobrir o motivo
  • Quando eu usava Windows, aquela janela de console ficava travada por horas
    No fim, se eu fechasse, o driver sumia no boot seguinte e eu precisava reinstalá-lo
    Era o pior programa de atualização automática que já usei