AMD will eine gemeldete Remote-Code-Execution-Schwachstelle (RCE) nicht beheben

 (mrbruh.com)
1 Punkte von GN⁺ 2026-02-07 | 1 Kommentare | Auf WhatsApp teilen
  • In der AutoUpdate-Software von AMD wurde eine Remote-Code-Execution-Schwachstelle (RCE) entdeckt und gemeldet, AMD hat jedoch entschieden, sie nicht zu beheben
  • Die in der Update-Konfigurationsdatei gespeicherte URL lädt ausführbare Dateien über das HTTP-Protokoll herunter und ist dadurch für MITM-Angriffe (Man-in-the-Middle) anfällig
  • Die Software ist so aufgebaut, dass sie die Signatur heruntergeladener Dateien nicht prüft und sie sofort ausführt
  • AMD hat dieses Problem als „out of scope“ eingestuft und nicht als Sicherheitslücke anerkannt
  • Obwohl das Risiko besteht, dass ein Netzwerkangreifer bösartige ausführbare Dateien verteilen kann, wird das Fehlen eines Patches als Sicherheitsproblem kritisiert

Wie die RCE-Schwachstelle in AMD AutoUpdate entdeckt wurde

  • Beim Nachverfolgen eines regelmäßig auftauchenden Konsolenfensters auf einem neuen Gaming-PC stellte sich heraus, dass die Ursache die AMD-AutoUpdate-Executable war
  • Beim Dekompilieren des Programms wurde zufällig eine RCE-Schwachstelle entdeckt
  • Die Update-URL ist in der Datei app.config gespeichert, und selbst in der Produktionsumgebung wird eine Development-URL verwendet
  • Diese URL nutzt zwar HTTPS, die tatsächlichen Download-Links für ausführbare Dateien verwenden jedoch HTTP

Technische Probleme der Schwachstelle

  • Da ausführbare Dateien über HTTP heruntergeladen werden, können Angreifer im Netzwerk oder auf ISP-Ebene die Antwort manipulieren und durch eine bösartige Datei ersetzen
  • Das AutoUpdate-Programm prüft weder Zertifikate noch Signaturen der heruntergeladenen Dateien
  • Dadurch kann ein Angreifer letztlich eine beliebige ausführbare Datei verteilen, die das Programm sofort ausführen kann

Reaktion von AMD und Ergebnis der Meldung

  • Nach der Entdeckung wurde die Schwachstelle an AMD gemeldet, aber als „won’t fix“ und „out of scope“ eingestuft und damit abgeschlossen
  • AMD betrachtet diese Schwachstelle nicht als Sicherheitsproblem
  • Der Zeitplan für Meldung und Veröffentlichung war wie folgt
    • 27/01/2026: Schwachstelle entdeckt
    • 05/02/2026: An AMD gemeldet
    • 05/02/2026: Als „wont fix/out of scope“ geschlossen
    • 06/02/2026: Blogbeitrag veröffentlicht

Sicherheitstechnische Implikationen

  • Eine HTTP-basierte Update-Struktur und fehlende Signaturprüfung können Benutzersysteme Remote-Code-Execution-Angriffen aussetzen
  • Die Entscheidung von AMD, dieses Problem nicht zu beheben, birgt Potenzial für Kontroversen in der Sicherheits-Community
  • Falls ein Netzwerkangreifer vorhanden ist, besteht das Risiko des Missbrauchs als Verteilungsweg für Schadsoftware

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-07
Hacker-News-Kommentare

  • Ein großer Vorteil davon, dass Linux alle Treiber mitliefert, ist, dass man keine minderwertige oder spywareartige Software zur Treiberverwaltung installieren muss
    Solche Programme lassen sich nur schwer sandboxen und sind sicherheitstechnisch riskant
    Interessanterweise wirken die Distributions-Maintainer, die kostenlos arbeiten, deutlich kompetenter in Sachen Sicherheit als Hardware-Hersteller mit Milliardenumsätzen

    • Es ist nicht so, dass Hardware-Hersteller unfähig in Sachen Sicherheit wären, sondern ihre Prioritäten liegen anders
      Für Distributions-Maintainer ist Sicherheit wichtig, während Hersteller es wichtiger finden, die nächste Hardware-Generation schnell auf den Markt zu bringen
      Letztlich verfolgen die beiden Gruppen unterschiedliche Ziele
    • Ich denke, diese Qualität bleibt dank der von Linus geschaffenen Struktur und der vielen Mitwirkenden erhalten
      Eine kleine Zahl einflussreicher Menschen leistet still gute Arbeit
      Dass diese Leute nicht in den Nachrichten auftauchen, ist für mich ein Zeichen dafür, dass dort die eigentlichen Könner sitzen
    • Ryzen Master ist kein Treiber
      Die meisten Funktionen sind unter Linux nicht verfügbar
    • Im ursprünglichen Beitrag ist nicht klar, ob das Problem ein Windows-spezifisches Thema ist
    • In letzter Zeit wechseln Hersteller zu einem Modell, bei dem ein lokaler Webserver läuft und Hardware über den Browser gesteuert wird, und das klingt sicherheitstechnisch nach einer schrecklichen Idee

  • Ich blockiere sämtlichen HTTP-Traffic
    Nicht nur bei AMD, auch bei Gigabyte, ASUS usw. schlagen automatische Updates fehl, wenn es keinen HTTP-Zugriff gibt
    Ein passender Reddit-Thread behandelt dieses Problem ebenfalls
    Unverschlüsselte HTTP-Anfragen sind ein Datenschutzleck und ein potenzieller MITM-Angriffsvektor
    Ein TLS-Stack ist ein deutlich schwierigeres Angriffsziel

    • Wenn die Payload signiert ist, ist das Vertrauensniveau bei HTTP und HTTPS ähnlich
      Am Ende vertraut man dem Code zur Signaturprüfung auf dem Client, das ist also nicht anders, als GPG zu vertrauen
    • Aber gehen dadurch nicht CRL- oder OCSP-Abfragen kaputt?
    • Viele Linux-Paket-Repositories verwenden immer noch nur HTTP
      Das ist praktisch, um installierte Paketversionen zu verfolgen, wirkt aber sicherheitstechnisch fragwürdig

  • Das ist wirklich ein ernstes Problem
    Es handelt sich um eine Situation, in der über einen HTTP-Redirect beliebige Codeausführung möglich ist, und so ein Programm ist auf unzähligen PCs installiert
    Es wäre so leicht, auf einem Flughafen einfach einen Wi-Fi-Hotspot zu öffnen und ATI-Grafiknutzer direkt anzugreifen

    • In meinem Land würde man für so etwas verhaftet
      Im Grunde ist das die einzige Präventionsmaßnahme durch Gesetz
    • Natürlich ist es schlecht, aber das funktioniert nur, wenn gerade ein Update ansteht
      Das heißt: nur wenn man ohne VPN mit einem riskanten Hotspot verbunden ist, AMD kürzlich ein Update verteilt hat und der Scheduler genau dann läuft
    • Wer verbindet sich schon mit dem Hotspot von jemand Fremdem?
      Aber wenn der lokale ISP bösartig ist, wird der Angriff viel einfacher
    • Ich schalte automatische Updates aus
      Seit Win98 halte ich automatische Updates für die dümmste Funktion überhaupt

  • Schon eine einzige DNS-Vergiftung reicht für einen Angriff
    Wenn zum Beispiel ein Router kompromittiert wurde und eine falsche IP zurückliefert, kann man in den HTTP-Traffic bösartige Binärdateien einschleusen
    HTTPS wird einfach durchgereicht, aber HTTP ist verwundbar
    Wer noch das Standard-Admin-Passwort verwendet, sollte es sofort ändern
    Dasselbe kann ein Angreifer auch mit DHCP-Spoofing oder einem gefälschten Wi-Fi tun

    • Nutzer per SSID-Spoofing oder Jamming mit einem bösartigen Wi-Fi zu verbinden, ist sehr einfach
    • Schon das frühere Senden einer DNS-Antwort kann für den Angriff ausreichen

  • Es ist schwer nachvollziehbar, dass AMD dieses Problem mit der Begründung außerhalb des Bug-Bounty-Scopes abgelehnt hat
    Schon der Verlust eines einzigen Kunden dürfte teurer sein als eine Bounty, daher sendet es ein falsches Signal, Sicherheit mit Verweis auf formale Scope-Dokumente zu ignorieren
    So eine Haltung wird dazu führen, dass Hacker AMD künftig nichts mehr melden

    • Tatsächlich wurde AMD auf dieses Problem mehrfach hingewiesen
      Deshalb wäre eine Belohnung selbst dann seltsam, wenn es im Scope läge

  • Das ist nicht bloß ein Versehen, sondern ein Versagen des Security-Reporting-Prozesses
    Sicherheitsabteilungen großer Unternehmen könnten auf dem Niveau diskutieren, AMD-Hardware oder die Update-App zu verbieten
    Wäre dafür eine CVE vergeben worden, wäre es ein Vorfall, der es in die Nachrichten schafft
    Ein Angreifer könnte in öffentlichem Wi-Fi oder beim ISP HTTP-Traffic überwachen und ausführbare Dateien infizieren

    • Jeder kann eine CVE beantragen, also könnte das am Ende der einzige Weg zu einer Behebung sein

  • AMD hat nicht gesagt, dass dies keine Schwachstelle sei, sondern nur, dass es außerhalb des Bug-Bounty-Scopes liege

    • Aber eine Schwachstelle zu ignorieren, die aus der Ferne eine Rechteausweitung ermöglichen kann, ist durch nichts zu entschuldigen
      Für Angreifer gibt es kein Konzept von „außerhalb des Scopes“, aber AMD macht genau das zu seiner Politik
      Das ist eindeutig eine sicherheitspolitisch verantwortungslose Regelung
    • Am Ende sagt man noch, dass bereits das Scope-Dokument von AMD selbst der eigentliche Bug ist

  • Das ist eine sehr ernste Schwachstelle
    Man sollte sie nicht kleinreden, nur weil „MitM erforderlich ist“
    Das Internet selbst ist bereits eine MitM-Umgebung

    • Tatsächlich braucht es nicht einmal MitM
      Schon ein bösartiger DHCP-Server, der DNS manipuliert, reicht für einen Angriff

  • Dass AMD den Bericht schon einen Tag später mit "out of scope / won't fix" geschlossen hat, wirkt viel zu vorschnell
    Das könnte auch einfach nur bedeuten, dass es nicht in den Bug-Bounty-Kanal fällt, und nicht zwingend, dass es tatsächlich nicht behoben wird

  • Auf meinem PC erscheint das AMD-AutoUpdate-Terminal jeden Tag um Mitternacht und ich muss es wegklicken
    Jetzt habe ich endgültig einen Grund, es komplett zu blockieren und wieder auf manuelle Updates umzusteigen

    • Ach, das war also dieses Fenster! Ich habe seit Tagen nach dem Grund gesucht
    • Früher unter Windows hing dieses Konsolenfenster bei mir stundenlang fest
      Wenn ich es dann geschlossen habe, war der Treiber beim nächsten Booten verschwunden und ich musste ihn neu installieren
      Das war das schlechteste Auto-Update-Programm, das ich je benutzt habe