Une vulnérabilité d’exécution de code à distance (RCE) qu’AMD a décidé de ne pas corriger

 (mrbruh.com)
1 points par GN⁺ 2026-02-07 | 1 commentaires | Partager sur WhatsApp
  • Une vulnérabilité d’exécution de code à distance (RCE) a été découverte et signalée dans le logiciel AutoUpdate d’AMD, mais AMD a décidé de ne pas la corriger
  • L’URL stockée dans le fichier de configuration de mise à jour utilise le protocole HTTP pour télécharger des exécutables, ce qui l’expose à une attaque MITM (homme du milieu)
  • Le logiciel est conçu pour exécuter immédiatement les fichiers téléchargés sans vérifier leur signature
  • AMD a classé ce problème comme « hors périmètre (out of scope) » et ne le reconnaît pas comme une vulnérabilité de sécurité
  • Bien qu’il existe un risque qu’un attaquant réseau puisse distribuer un exécutable malveillant, l’absence de correctif est pointée comme une préoccupation de sécurité

Découverte de la vulnérabilité RCE dans AMD AutoUpdate

  • En cherchant l’origine d’une fenêtre console qui apparaissait périodiquement sur un nouveau PC gaming, il a été confirmé que la cause était l’exécutable AMD AutoUpdate
  • Lors de la décompilation du programme, une vulnérabilité RCE a été découverte par hasard
  • L’URL de mise à jour est stockée dans le fichier app.config, et même en production, c’est une URL de développement (Development) qui est utilisée
  • Cette URL utilise HTTPS, mais les liens de téléchargement des exécutables pointent en réalité vers HTTP

Problèmes techniques de la vulnérabilité

  • Comme les exécutables sont téléchargés via HTTP, un attaquant présent sur le réseau ou au niveau du FAI peut modifier la réponse et la remplacer par un fichier malveillant
  • Le programme AutoUpdate ne vérifie ni le certificat ni la signature des fichiers téléchargés
  • En conséquence, un attaquant peut distribuer un exécutable arbitraire, que le programme peut lancer immédiatement

Réponse d’AMD et résultat du signalement

  • Après la découverte, la vulnérabilité a été signalée à AMD, mais le dossier a été clôturé comme « won’t fix » et « hors périmètre (out of scope) »
  • AMD ne considère pas cette vulnérabilité comme un problème de sécurité
  • Le calendrier du signalement et de la publication est le suivant
    • 27/01/2026 : découverte de la vulnérabilité
    • 05/02/2026 : signalement à AMD
    • 05/02/2026 : clôture en « wont fix/out of scope »
    • 06/02/2026 : publication du billet de blog

Implications en matière de sécurité

  • Une architecture de mise à jour reposant sur HTTP et l’absence de vérification de signature peuvent exposer les systèmes des utilisateurs à des attaques d’exécution de code à distance
  • La décision d’AMD de ne pas corriger ce problème laisse entrevoir une possible controverse au sein de la communauté sécurité
  • En présence d’un attaquant réseau, il existe un risque d’exploitation comme vecteur de distribution de malware

À lire aussi

1 commentaires

 
GN⁺ 2026-02-07
Avis sur Hacker News

  • Une bonne raison pour laquelle Linux intègre tous les pilotes, c’est qu’il n’y a pas besoin d’installer des logiciels de gestion de pilotes de mauvaise qualité, voire assimilables à des spyware
    Ces programmes sont difficiles à sandboxer et présentent des risques de sécurité
    Fait intéressant, on dirait que des mainteneurs de distribution travaillant bénévolement sont bien plus compétents en sécurité que des fabricants de matériel pesant des dizaines de milliards de dollars

    • Ce n’est pas que les fabricants de matériel sont incompétents en sécurité, c’est simplement qu’ils ont d’autres priorités
      Les mainteneurs de distribution accordent de l’importance à la sécurité, tandis que les vendeurs privilégient la sortie rapide de la prochaine génération de matériel
      Au final, les deux groupes poursuivent des objectifs différents
    • Je pense que cette qualité est maintenue grâce à l’organisation mise en place par Linus et aux innombrables contributeurs qui y participent
      Un petit nombre de personnes influentes fait discrètement du très bon travail
      À mon avis, le fait qu’on ne voie jamais ces gens dans l’actualité est justement le signe qu’ils sont vraiment compétents
    • Ryzen Master n’est pas un pilote
      La plupart de ses fonctionnalités ne sont pas disponibles sous Linux
    • Le problème dans le billet d’origine n’indique pas clairement s’il s’agit d’un sujet propre à Windows
    • En ce moment, les vendeurs semblent évoluer vers un modèle où ils lancent un serveur web local pour contrôler le matériel via le navigateur, et ça ressemble à une idée catastrophique sur le plan de la sécurité

  • Je bloque tout le trafic HTTP
    Pas seulement chez AMD : chez Gigabyte, ASUS, etc., les mises à jour automatiques échouent aussi sans accès HTTP
    Ce fil Reddit lié traite également du problème
    Les requêtes HTTP non chiffrées constituent une fuite de vie privée et un vecteur potentiel d’attaque MitM
    Une pile TLS est une cible bien plus difficile à attaquer

    • Si la charge utile est signée, le niveau de confiance est à peu près le même en HTTP qu’en HTTPS
      Au final, on fait confiance au code de vérification de signature du client, ce qui n’est pas différent du fait de faire confiance à GPG
    • Mais dans ce cas, est-ce que ça ne casse pas les vérifications CRL ou OCSP ?
    • De nombreux dépôts de paquets Linux utilisent encore uniquement HTTP
      C’est pratique pour suivre les versions de paquets installées, mais ça reste inquiétant du point de vue de la sécurité

  • C’est vraiment un problème grave
    Il est possible d’obtenir une exécution de code arbitraire via une redirection HTTP, et ce logiciel est installé sur un très grand nombre de PC
    Il suffirait presque d’ouvrir un hotspot Wi-Fi dans un aéroport pour attaquer immédiatement les utilisateurs de cartes graphiques ATI

    • Dans mon pays, faire ça conduit à une arrestation
      En somme, la loi est le seul véritable moyen de prévention
    • Bien sûr que c’est mauvais, mais cela ne fonctionne qu’au moment où une mise à jour est disponible
      Donc il faut être connecté à un hotspot risqué sans VPN, qu’AMD ait récemment publié une mise à jour, et que le planificateur s’exécute à ce moment-là
    • Qui se connecterait au hotspot d’un inconnu ?
      Mais si le FAI local est malveillant, l’attaque devient beaucoup plus simple
    • Moi, je désactive les mises à jour automatiques
      Depuis l’époque de Win98, je pense que les mises à jour automatiques sont la fonctionnalité la plus stupide

  • Il suffit de polluer le DNS une seule fois pour que l’attaque devienne possible
    Par exemple, si le routeur a été piraté et renvoie une mauvaise IP, il devient possible d’injecter un binaire malveillant dans le trafic HTTP
    Le HTTPS passe sans problème, mais le HTTP est vulnérable
    Les gens qui utilisent encore le mot de passe administrateur par défaut devraient le changer immédiatement
    Un attaquant peut faire la même chose avec du spoofing DHCP ou un faux Wi‑Fi

    • Il est très facile de connecter un utilisateur à un Wi‑Fi malveillant via du spoofing de SSID ou du brouillage radio
    • Il suffit aussi d’envoyer la réponse DNS en premier pour réussir l’attaque

  • Il est difficile de comprendre pourquoi AMD a rejeté ce problème en disant qu’il était hors du périmètre du bug bounty
    Perdre ne serait-ce qu’un seul client coûterait probablement plus cher que la prime, et invoquer le périmètre documentaire pour ignorer la sécurité envoie un très mauvais signal
    Une telle attitude fera que les hackers ne signaleront plus de problèmes à AMD à l’avenir

    • En réalité, AMD s’est déjà fait signaler ce problème à plusieurs reprises
      Donc même si c’était dans le périmètre, il serait presque étrange qu’il donne lieu à une récompense

  • Ce n’est pas une simple erreur, c’est l’échec d’un processus de remontée de sécurité
    Les équipes sécurité de grandes entreprises pourraient aller jusqu’à discuter de l’interdiction du matériel AMD ou de son application de mise à jour
    Si cela avait été enregistré comme CVE, cela aurait été le genre d’incident qui finit dans l’actualité
    Un attaquant peut surveiller le trafic HTTP sur un Wi‑Fi public ou chez un FAI et infecter des exécutables

    • N’importe qui peut demander un CVE, donc c’est peut-être au final la seule voie menant à un correctif

  • AMD n’a pas dit que ce n’était pas une vulnérabilité ; AMD a seulement dit que c’était hors du périmètre du bug bounty

    • Mais ignorer une vulnérabilité permettant une élévation de privilèges à distance est indéfendable
      Pour un attaquant, la notion de « hors périmètre » n’existe pas, alors qu’AMD en a fait une règle de politique interne
      C’est une politique d’irresponsabilité en matière de sécurité tout à fait manifeste
    • On en arrive presque à dire que c’est le document de périmètre d’AMD lui-même qui est bogué

  • C’est une vulnérabilité très grave
    Il ne faut pas la minimiser sous prétexte qu’« il faut un MitM »
    Internet est déjà en soi un environnement MitM

    • En réalité, même un MitM n’est pas nécessaire
      Un serveur DHCP malveillant manipulant le DNS suffit pour permettre l’attaque

  • Le fait qu’AMD ait clos le signalement en une journée avec « out of scope / won't fix » semble beaucoup trop précipité
    Cela signifie peut-être seulement que le problème ne relève pas du canal bug bounty, pas forcément qu’ils n’ont réellement pas l’intention de le corriger

  • Sur mon PC, le terminal AMD AutoUpdate s’ouvre chaque jour à minuit et je dois le fermer
    Voilà désormais une bonne raison de le bloquer complètement et de revenir aux mises à jour manuelles

    • Ah, c’était donc cette fenêtre-là ! Je cherchais depuis plusieurs jours d’où elle venait
    • À l’époque où j’utilisais Windows, cette fenêtre de console restait parfois bloquée pendant des heures
      Et si je la fermais, le pilote disparaissait au démarrage suivant et il fallait le réinstaller
      C’était le pire programme de mise à jour automatique que j’aie jamais utilisé