AMDs Skitter-Schwachstelle eröffnet tiefgreifende Hardware-Kontrolle jenseits des Suchrauschens um amazon amd
AMD sieht sich nun mit einer bemerkenswerten Sicherheitsbehauptung zu Prozessoren konfrontiert, die ungefähr zwischen 2011 und 2015 erschienen sind. Berichten zufolge legt eine einzige Instruktion Speicher offen, den die Hardware normalerweise unzugänglich hält.
Der Exploit mit dem Namen Skitter Creek Bath Salts, kurz Skitter, zielt auf AMD-Prozessoren der Familien 15h und 16h. Sicherheitsexperte Christopher Domas entwickelte die Technik laut der ersten Berichterstattung zu Skitter.
Die Formulierung amazon amd taucht in der Recherche zu dieser Geschichte auf, doch im Mittelpunkt steht kein bekannt gewordener Amazon-Vorfall. Die betroffene Hardware stammt von AMD, und die verfügbare Berichterstattung belegt keine Verbindung zu Amazon.
Diese Unterscheidung ist wichtig, denn das zugrunde liegende Sicherheitsproblem ist auch ohne eine Ausweitung über die Beweislage hinaus ernst genug. Skitter verändert Berichten zufolge eine Zuordnungssteuerung, die mehrere hochprivilegierte Speicherbereiche schützt.
Zu diesen Bereichen gehört Speicher im Zusammenhang mit dem Platform Security Processor, kurz PSP, der Sicherheitsfunktionen außerhalb des Hauptbetriebssystems ausführt. Dazu zählen außerdem System Management Mode, Speicher für Microcode-Patches und weitere implementierungsspezifische Bereiche.
Der Zugriff auf diese Komponenten würde einen Angreifer unterhalb gewöhnlicher Anwendungen, des Betriebssystems und vieler Schutzwerkzeuge positionieren. Eine technische Fähigkeit führt jedoch nicht automatisch zu einem praktikablen Remote-Angriff.
Der zentrale Konflikt besteht daher nicht zwischen AMD und einem anderen Chipanbieter. Es geht um die zugesicherte Hardware-Isolation des Prozessors gegen einen Mechanismus, der diese Isolation Berichten zufolge mit einer Instruktion deaktiviert.
Ältere Systeme bilden den kritischen Punkt. Sie bleiben oft noch lange nach dem Ende normaler Upgrade-Zyklen für Verbraucher in Industrieanlagen, eingebetteten Produkten, Laboren, Büros und Enthusiasten-PCs im Einsatz.
Skitter bedeutet nicht, dass jeder solche Computer bereits kompromittiert ist. Es bedeutet, dass Eigentümer feststellen müssen, ob ein alter Prozessor die Grenzen noch schützt, von denen ihr Sicherheitsmodell ausgeht.
Was Skitter Berichten zufolge in AMD-CPUs verändert
Skitter verwandelt Berichten zufolge ein einzelnes Steuerbit in ein Tor zu Speicherbereichen, die normale Software nicht abbilden kann.
Moderne Prozessoren führen mehr aus als Anwendungsinstruktionen. Sie trennen Speicher auch zwischen Betriebssystemen, Firmware, Geräten, Hypervisoren und internen Sicherheitsprozessoren.
Diese Trennung bestimmt, welche Komponente jede Adresse lesen oder verändern kann. Sie verhindert, dass gewöhnliche Software geschützten Firmware-Speicher wie einen normalen Anwendungspuffer behandelt.
Laut dem ersten Bericht enthalten Prozessoren der Familien 15h und 16h ein Bit, das diese Zuordnungsbeschränkung deaktiviert. Domas soll herausgefunden haben, dass eine Instruktion das Bit verändern kann.
Das unmittelbare Ergebnis ist nicht einfach ein weiterer Zugewinn an Software-Berechtigungen. Die Änderung legt angeblich Bereiche offen, die selbst für herkömmlichen Code auf Kernel-Ebene unzugänglich bleiben.
Ein Ziel ist der Platform Security Processor. Der PSP ist ein dediziertes Sicherheitssubsystem, das vertrauenswürdige Vorgänge getrennt von den Hauptkernen des x86-Prozessors ausführt.
Funktionen eines Firmware Trusted Platform Module können von diesem Subsystem abhängen. Ein fTPM speichert oder verarbeitet Messwerte und kryptografisches Material für Funktionen wie Plattformattestierung.
Der Exploit legt Berichten zufolge auch den System Management Mode offen. SMM ist ein Prozessorbetriebsmodus, den Firmware für grundlegende Funktionen wie Energieverwaltung und Hardwaremanagement verwendet.
Wenn SMM ausgeführt wird, pausiert das normale Betriebssystem. Sein Code befindet sich in einem geschützten Bereich, der üblicherweise SMRAM genannt wird und auf den gewöhnliche Software keinen Zugriff haben sollte.
Microsoft beschreibt SMM als seit Langem attraktives Angriffsziel, da es traditionell weitreichende Kontrolle über Speicher und Geräte besitzt. Die Arbeiten zur SMM-Isolation zeigen, warum Anbieter diese Ebene als privilegierter als das Betriebssystem behandeln.
RAM für Microcode-Patches ist ein weiteres berichtetes Ziel. Microcode übersetzt oder steuert Teile der Prozessorimplementierung architektonischer Instruktionen.
Anbieter verwenden Microcode-Updates, um Prozessorverhalten zu korrigieren, ohne einen Chip physisch austauschen zu müssen. Unbefugter Zugriff könnte daher Annahmen auf Instruktionsebene gefährden.
Die aktuelle Berichterstattung beschreibt zudem Zugriff auf weitere geschützte Implementierungsbereiche. Ihre genaue Relevanz hängt vom Prozessormodell, der Firmware, dem Boarddesign und dem Angriffspfad ab.
Diese Breite erklärt die Beschreibung als „vollständige Kontrolle auf Hardwareebene“. Dennoch sollte die Formulierung das potenzielle Privilegienniveau beschreiben, nicht eine automatisch zuverlässige Kompromittierung jeder betroffenen Maschine.
Ein vollständiger Exploit muss nach dem Öffnen der Zuordnung etwas Nützliches tun. Er muss die Zielregion identifizieren, Modellunterschiede bewältigen und den Zustand verändern, ohne das System zum Absturz zu bringen.
Diese technischen Schritte trennen ein architektonisches Grundelement von zuverlässiger Malware. Die berichtete Einfachheit von Skitter betrifft die Aktion zum Öffnen der Grenze, nicht zwingend die gesamte Angriffskette.
Die Behauptung bleibt ungewöhnlich wichtig, weil Speicherisolation grundlegend sein soll. Software-Schutzmaßnahmen oberhalb dieser Grenze können nicht vollständig kompensieren, wenn die Hardware geschützten Zustand offenlegt.
Die betroffenen Familien umfassen mehr als eine bekannte Desktop-Reihe
Das Risiko folgt Prozessorfamilienkennungen, nicht dem AMD-Logo oder einer allgemeinen Suchformulierung wie amazon amd.
Familie 15h umfasst mehrere Architekturen, die in AMDs Zeit vor Zen verkauft wurden. Zu den bekanntesten Beispielen gehören von Bulldozer abgeleitete FX-Desktopprozessoren sowie verwandte Server- oder Accelerated-Processor-Designs.
AMDs archivierter Leitfaden zu Familie 15h dokumentiert, wie Firmware und Kernel frühe Mitglieder dieser Familie identifizieren und konfigurieren. Er verdeutlicht auch, warum eine Familienbezeichnung mehr als einen Handelsnamen umfasst.
Familie 16h umfasst stromsparende Accelerated Processing Units und eingebettete Systeme. AMD-Dokumentation nennt innerhalb der Familie Desktop-, Notebook-, Tablet- und Embedded-Varianten.
Der archivierte Leitfaden zu Familie 16h des Unternehmens wurde im Februar 2015 überarbeitet. Dieser Zeitpunkt passt zum berichteten Endpunkt der betroffenen Generation.
Eigentümer sollten die Betroffenheit nicht allein anhand eines Marketplace-Angebots bestimmen. Handelsnamen, wiederverwendete Produktbezeichnungen und unvollständige Verkäuferbeschreibungen können die zugrunde liegende Familie und das Modell verschleiern.
Die CPUID-Daten des Prozessors bieten einen belastbareren Ausgangspunkt. Betriebssystemwerkzeuge können Familie, Modell und Stepping anzeigen, ohne experimentellen Sicherheitscode auszuführen.
Ein Modellname hilft weiterhin bei der Inventarisierung. Er sollte jedoch gegen die Familienkennung geprüft werden, statt als entscheidender Nachweis zu gelten.
Diese Unterscheidung wird besonders außerhalb von Consumer-Desktops wichtig. Eingebettete Boards können über Jahre im Einsatz bleiben, weil ihr Austausch Validierung, physischen Zugang oder Zertifizierungsarbeit erfordert.
Ein Kassenterminal, ein Laborcontroller oder ein Fabrikcomputer kann eine eng abgegrenzte Aufgabe zuverlässig erfüllen. Sein Eigentümer sieht möglicherweise kaum operative Gründe für einen Austausch.
Sicherheit verändert diese Rechnung. Eine Maschine wird nicht allein deshalb risikoarm, weil ihre Arbeitslast vorhersehbar oder ihre Benutzeroberfläche eingeschränkt ist.
Die Dokumentation zu Familie 16h umfasst eingebettete G-Series-Systeme neben Consumer-Konfigurationen. AMDs Embedded-Datenblatt führt Dual-Core- und Quad-Core-Optionen mit 32-Bit- und 64-Bit-Kompatibilität auf.
Diese Breite schafft eine Herausforderung bei der Inventarisierung. Unternehmen wissen möglicherweise, dass sie AMD-Systeme besitzen, verfügen aber nicht über die Aufzeichnungen auf Modellebene, die für eine schnelle Bewertung der Betroffenheit nötig sind.
Der betroffene Zeitraum liegt zudem vor den heutigen Hardware-Beschaffungspraktiken vieler Unternehmen. Asset-Datenbanken können ein Gerät aufführen, jedoch nicht dessen Prozessorfamilie oder Firmware-Status.
Käufer gebrauchter Hardware stehen vor einem weiteren Problem. Ältere FX-Desktops und kompakte Systeme zirkulieren weiterhin, weil sie grundlegende Computeraufgaben, Retro-Gaming, Tests und spezialisierte Software bewältigen können.
Ein Angebot, das über eine amazon amd-Suche gefunden wurde, belegt nicht, ob ein Prozessor betroffen, gepatcht, isoliert oder zuvor verändert wurde. Käufer benötigen das genaue Modell und Details zum Board.
Sie müssen auch die Mainboard-Firmware berücksichtigen. Prozessorsicherheit funktioniert selten unabhängig von BIOS-Konfiguration, Firmware-Handlern und anbieterspezifischen Bereitstellungsentscheidungen.
Die praktische Bewertungseinheit ist daher die gesamte Plattform. Dazu gehören Prozessor, Board, Firmware-Version, Betriebssystem, Treiber und physische Bereitstellung.
Der Ein-Instruktions-Mechanismus stellt die Hardware-Isolation infrage
Skitter ist relevant, weil der berichtete Mechanismus eine Grenze umgeht, statt lediglich darüber ausgeführten Code auszunutzen.
Die meisten Software-Schwachstellen beginnen mit einem Fehler in einer Anwendung, einem Treiber, einer Betriebssystemkomponente oder einem Firmware-Handler. Angreifer manipulieren diesen Fehler, um eine höhere Berechtigungsstufe zu erreichen.
Skitter nimmt Berichten zufolge einen anderen Weg. Seine Schlüsseloperation verändert, wie geschützte physische Adressen für den Hauptprozessor offengelegt werden.
Dadurch wird die Speicherkarte selbst zum zentralen Sicherheitsmechanismus. Sie definiert, ob eine bestimmte Adresse gewöhnlichen Speicher, ein Gerät oder eine interne geschützte Komponente erreicht.
Eine Steuerung, die die Beschränkung deaktiviert, kann mehrere getrennte Vertrauensgrenzen gleichzeitig zum Einsturz bringen. Das Betriebssystem kann einen Bereich nicht sicher vermitteln, den der Prozessor unerwartet sichtbar macht.
Dies ist die zentrale Umkehrung. Hardwaregestützte Isolation dient normalerweise als letzte Verteidigung, wenn gewöhnliche Software-Berechtigungen bereits verloren sind.
Skitter verwandelt diese letzte Verteidigung Berichten zufolge in eine Angriffsfläche. Derselbe Mechanismus, der Zugriffe ordnen soll, wird zum Weg um Zugriffskontrollen herum.
Christopher Domas hat Erfahrung mit der Erforschung von Prozessorverhalten unterhalb normaler Softwaregrenzen. Zu seinen früheren Arbeiten gehören der Prozessor-Fuzzer Sandsifter und die Privilegieneskalationstechnik Memory Sinkhole.
Eine Konferenzbiografie zu seiner Prozessorforschung nennt zudem God Mode Unlocked, das Hardware-Hintertüren in x86-Prozessoren untersuchte. Dieser Hintergrund liefert Kontext, bestätigt jedoch nicht unabhängig jede Skitter-Behauptung.
Die neue Technik sollte außerdem von Domas' früherer Arbeit zu Memory Sinkhole unterschieden werden. Memory Sinkhole manipulierte das Verhalten eines speicherabgebildeten Interrupt-Controllers, um geschützten SMM-Speicher zu beeinträchtigen.
Skitter wird als AMD-spezifische Umgehung der Speicherzuordnung beschrieben, die Familie 15h und 16h betrifft. Der berichtete Zugriff auf PSP und Microcode erweitert seine Zielmenge.
Beide Ansätze stellen die Annahme infrage, dass geschützter Firmware-Speicher nach dem Bootvorgang unerreichbar ist. Ihre Mechanismen und betroffenen Prozessoren sollten nicht gleichgesetzt werden.
Eine einzige Instruktion bedeutet auch nicht, dass eine nicht privilegierte Website sofort einen Computer übernehmen kann. Prozessorsteuerinstruktionen erfordern häufig einen privilegierten Ausführungskontext.
Der verfügbare öffentliche Bericht braucht klarere Antworten zu dieser Voraussetzung. Leser sollten nach einem eindeutigen Nachweis suchen, der zeigt, welche Privilegienstufe erforderlich ist, bevor sich das Mapping-Bit ändern kann.
Falls Kernel-Privilegien erforderlich sind, bräuchten Angreifer zunächst eine weitere Schwachstelle, einen bösartigen Treiber oder autorisierten administrativen Zugriff. Skitter würde dann einen bereits bestehenden Kompromittierungszustand vertiefen.
Dieses Szenario bleibt ernst. Kernel-Zugriff kann mächtig sein, doch Verteidiger verlassen sich weiterhin auf PSP, SMM und Firmware-Isolation, um Geheimnisse und Persistenzgrenzen zu schützen.
Ein Angreifer, der diese Ebenen erreicht, könnte eine Neuinstallation des Betriebssystems potenziell überstehen. Er kann sich zudem vor Endpoint-Tools verbergen, die nur normalen Speicher und Prozesse beobachten.
Persistenz ist jedoch nicht allein durch Speicherzugriff garantiert. Ein Angreifer muss einen dauerhaften Änderungspfad finden und plattformspezifisches Firmware-Verhalten bewältigen.
Zuverlässigkeit ist wichtig, weil beschädigter Microcode- oder Firmware-Zustand den Prozessor anhalten kann. Ein abstürzender Proof of Concept hat einen anderen operativen Wert als ein stabiles Implantat.
Deshalb sind unabhängige technische Materialien unverzichtbar. Forschende benötigen die Instruktion, die Registerdefinition, betroffene Steppings, Voraussetzungen und reproduzierbare Ergebnisse auf mehreren Mainboards.
Solange diese Details nicht öffentlich sind, ist die belastbarste Schlussfolgerung eng gefasst. Das berichtete Primitive untergräbt die Hardware-Isolation auf bestimmten Generationen, doch seine praktische Ausnutzbarkeit ist weiterhin unvollständig dokumentiert.
PSP, SMM und Microcode schaffen drei unterschiedliche Sicherheitsrisiken
Die offengelegten Bereiche gehören zu verschiedenen Vertrauensdomänen; daher erzeugt jeder ein eigenes Risiko statt eines einzigen allgemeinen Übernahmeszenarios.
Der PSP ist wichtig, weil er außerhalb des zentralen x86-Betriebssystems arbeitet. Sicherheitsdienste können von ihm abhängen, selbst wenn gewöhnliche Software Administratorrechte besitzt.
Das fTPM ist ein Beispiel. Es unterstützt Messungen und Schlüssel, die von Sicherheitsfunktionen des Betriebssystems verwendet werden, doch Implementierungen und Schlüsselverwaltung unterscheiden sich je nach Plattform.
Zugriff auf PSP-bezogenen Speicher legt nicht automatisch jeden geschützten Schlüssel offen. Er gibt jedoch Anlass zu hinterfragen, welche Daten sichtbar oder veränderbar werden.
Untersuchende müssen feststellen, ob Skitter laufenden PSP-Speicher, gemeinsam genutzte Kommunikationspuffer, Firmware-Images oder alle drei offenlegt. Jedes Ergebnis bringt eine andere Bedrohung mit sich.
SMM stellt ein separates Problem dar. Firmware nutzt es zur Hardwareverwaltung und verbirgt dabei seine Ausführung und seinen Speicher vor dem Betriebssystem.
Dort ausgeführter Code kann Speicher oder Geräte untersuchen, ohne als normaler Prozess zu erscheinen. Diese Undurchsichtigkeit macht SMM für persistente Implantate attraktiv.
Die Sicherheitsleitlinien von Microsoft erläutern, wie neuere Schutzmaßnahmen SMM durch authentifizierten Code und eingeschränkte Seiten begrenzen. Diese späteren Abwehrmaßnahmen verdeutlichen auch, was älteren Plattformen fehlt.
Wenn Skitter normalem x86-Code erlaubt, SMRAM zu lesen oder zu verändern, würde dies die grundlegenden Annahmen zu Vertraulichkeit und Integrität rund um SMM schwächen. Firmware-Bugs wären dann nicht mehr der einzige Weg hinein.
Microcode-Patch-RAM wirft eine noch grundlegendere Frage auf. Microcode beeinflusst, wie der Prozessor Instruktionen ausführt und außergewöhnliche Bedingungen verarbeitet.
Eine erfolgreiche Änderung könnte das Verhalten unterhalb des Betriebssystems potenziell verändern. Nützlichen Microcode zu schreiben ist jedoch schwierig, modellspezifisch und nur unzureichend dokumentiert.
Die Unterscheidung zwischen Lesen und Schreiben ist bei allen drei Zielen entscheidend. Lesezugriff kann Geheimnisse offenlegen, während Schreibzugriff Kontrolle oder Persistenz ermöglichen kann.
Der erste Bericht beschreibt breit angelegten Zugriff auf Hardwareebene, doch eine vollständige Bewertung braucht für jeden Bereich separate Nachweise. Ein erfolgreiches Mapping belegt nicht überall dieselbe Kontrolle.
Verteidiger sollten außerdem fragen, ob der Zustand einen Neustart übersteht. Flüchtiger Patch-RAM kann zurückgesetzt werden, während kompromittierter Firmware-Speicher eine Änderung beim Start wiederherstellen könnte.
Die Antwort bestimmt die Strategie für die Incident Response. Ein flüchtiger Laborexploit kann nach Stromverlust verschwinden, ein Firmware-Implantat erfordert jedoch einen umfassenderen Wiederherstellungsprozess.
Hier kann sensationsheischende Wortwahl nützliche Analysen verschleiern. „Vollständige Kontrolle“ klingt nach einem einzelnen Zustand, obwohl Hardwareplattformen mehrere unabhängige Ausführungs- und Speicherdomänen enthalten.
Ein sorgfältiger Bericht sollte angeben, welche Komponente gelesen, welche verändert und wie das Ergebnis verifiziert wurde. Außerdem sollte er erklären, ob Secure Boot den Test beeinflusst hat.
Keine Belege in der verfügbaren Berichterstattung verknüpfen die Schwachstelle mit Amazon-Infrastruktur. Das Schlüsselwort amazon amd ist daher ein Suchartefakt, keine belegte Aussage zu einem betroffenen Opfer.
Das ist für Cloud-Kunden wichtig. Das Risiko in Public Clouds hängt von den tatsächlich eingesetzten Prozessoren, Hypervisor-Kontrollen, dem Hardwarealter und dem innerhalb einer Gastinstanz verfügbaren Zugriff ab.
Eine virtuelle Gastmaschine kann normalerweise keine beliebigen privilegierten Host-Instruktionen ausführen. Selbst wenn sie die Instruktion kodieren könnte, sollte der Hypervisor gefährliche Operationen abfangen oder ablehnen.
Eine Behauptung zur Cloud-Ausnutzung würde Belege erfordern, dass ein Gast die verwundbare Host-Steuerung erreichen kann. Solche Belege erscheinen im geprüften Material nicht.
Organisationen sollten einen Befund zu einer Prozessorfamilie nicht in eine unbelegte Behauptung über einen Cloud-Einbruch verwandeln. Sie sollten das Problem auch nicht abtun, weil bislang kein Remote-Angriff bekannt geworden ist.
Lokale oder verkettete Schwachstellen können nach dem Erstzugriff wertvolle Werkzeuge werden. Tiefe Persistenz ist oft besonders für fortgeschrittene Angreifer relevant, die bereits über andere Einstiegsmöglichkeiten verfügen.
Die größte Unbekannte ist die tatsächliche Angriffsvoraussetzung
Die ungeklärte Frage lautet nicht, ob geschützter Speicher wichtig ist, sondern was ein Angreifer kontrollieren muss, bevor Skitter funktioniert.
Eine Prozessorinstruktion wird innerhalb eines Privilegienmodells ausgeführt. Einige Instruktionen laufen in normalen Anwendungen, andere erfordern Kernel- oder Firmware-Befugnisse.
Diese Voraussetzung bestimmt, ob Skitter eine Schwachstelle für den Ersteinstieg oder eine Eskalationstechnik nach einer Kompromittierung ist. Die beiden Kategorien verlangen unterschiedliche Reaktionen.
Falls unprivilegierter Code die Mapping-Änderung auslösen kann, wäre die Gefährdung ungewöhnlich breit. Browser, Dokumentenleser oder gewöhnliche Dienste könnten über separate Codeausführungsfehler mögliche Angriffswege werden.
Falls Ring-Zero-Zugriff erforderlich ist, beginnt Skitter erst, nachdem das Betriebssystem bereits tiefgreifend kompromittiert wurde. Sein Hauptwert läge dann in Umgehung von Schutzmaßnahmen, Zugriff auf Geheimnisse und Persistenz unterhalb des Kernels.
Keine der beiden Interpretationen macht den Fehler trivial. Sie verändern jedoch seine Dringlichkeit, die wahrscheinlichen Angreifer und die möglichen Abhilfemaßnahmen.
Die frühere Memory-Sinkhole-Technik erforderte Kernel-Privilegien, um ein modellspezifisches Register umzuprogrammieren. Zeitgenössische Analysen stellten fest, dass ein bösartiger Treiber diesen Zugriff ermöglichen könnte.
Skitter könnte eine andere Instruktion und Steuerung verwenden. Leser sollten nicht von identischen Voraussetzungen ausgehen, bis Domas oder AMD endgültige technische Details veröffentlicht.
Eine weitere Unbekannte ist der genaue Bereich betroffener Steppings. Prozessorfamilien umfassen mehrere Modelle, Revisionen und integrierte Produkte.
Die Dokumentation von AMD empfiehlt Software, Errata anhand von Daten zu Familie, Modell und Stepping zu identifizieren. Eine familienweite Kennzeichnung kann anfangs nützlich, für die Behebung jedoch unzureichend sein.
Die Firmware-Abhängigkeit fügt eine weitere Variable hinzu. Ein Mainboard-Hersteller kann Speicherbereiche anders konfigurieren oder Kontrollen hinzufügen, die eine Ausnutzung erschweren.
Eine zuverlässige Testmatrix sollte mehrere Desktop-, Mobil- und Embedded-Systeme umfassen. Sie sollte außerdem Firmware-Revisionen und Standardsicherheitseinstellungen vergleichen.
Aus der verfügbaren Berichterstattung bleibt die Abhilfe unklar. Ein Microcode-Update könnte die betreffende Steuerung sperren, aber nur AMD kann bestätigen, ob betroffene Hardware diese Korrektur unterstützt.
Ein Firmware-Update könnte möglicherweise den Auslösepfad blockieren oder die Instruktion überwachen. Das hängt davon ab, wann der Prozessor die Steuerung auswertet und welche Abfangfunktionen vorhanden sind.
Auch Betriebssystemschutzmaßnahmen können helfen, wenn der Angriff einen Treiber erfordert. Treiber-Positivlisten, virtualisierungsbasierte Sicherheit und Kernel-Integritätsprüfungen können den Zugriff auf privilegierte Instruktionen verringern.
Diese Maßnahmen reparieren keine fehlerhafte Hardwaregrenze. Sie erschweren es Angreifern, den Punkt zu erreichen, an dem die Grenze deaktiviert werden kann.
Physische Isolation bleibt für Systeme nützlich, die keine Korrekturen erhalten können. Ein Einzweck-Controller ohne Netzwerkzugang hat eine kleinere Remote-Angriffsfläche.
Wechselmedien, Wartungs-Laptops, Remote-Management-Schnittstellen und Hersteller-Updates können jedoch weiterhin privilegierten Code einführen. „Air-gapped“ sollte verifizierte Kontrollen beschreiben, keine Annahme.
Besitzer sollten dem Herunterladen inoffizieller Proof-of-Concept-Tools auf Produktionssysteme widerstehen. Low-Level-Experimente können einen Computer einfrieren, Zustände beschädigen oder spätere forensische Arbeit erschweren.
Eine sichere Reaktion beginnt mit einer Inventarisierung. Erfassen Sie Prozessorfamilie, Modell, Stepping, Mainboard, Firmware-Revision, Betriebssystem und Geschäftsfunktion.
Ermitteln Sie anschließend, ob das Gerät Geheimnisse oder privilegierte Workloads verarbeitet. Domänenanmeldedaten, Festplattenverschlüsselungsmaterial, Signiervorgänge und Zugriff auf industrielle Steuerungen erhöhen den Einsatz.
Suchen Sie dann nach einem AMD-Sicherheitsbulletin oder Mainboard-Hinweis, der die betreffenden Modelle nennt. Allgemeine Update-Empfehlungen reichen nicht aus, wenn Hersteller den Support eingestellt haben.
Die Formulierung amazon amd sollte keine Abhilfemaßnahmen leiten. Entscheidend sind die genaue Hardwareidentität und maßgebliche Herstellerleitlinien.
Worauf Besitzer und Forschende als Nächstes achten sollten
Drei Signale werden entscheiden, ob Skitter zu einer praktischen Sicherheitskrise wird oder eine begrenzte Technik nach einer Kompromittierung bleibt.
Das erste Signal ist eine vollständige technische Offenlegung durch Domas. Sie sollte die Instruktion, das Steuerbit, Voraussetzungen, getestete Prozessoren und die Verifikationsmethode identifizieren.
Diese Offenlegung würde unabhängigen Forschenden ermöglichen, die Mapping-Änderung zu reproduzieren. Eine Reproduktion auf mehreren Mainboards würde die familienweite Behauptung stärken.
Sie würde zudem zeigen, ob eine Instruktion nur die erste Stufe abschließt. Forschende könnten dann die Entfernung der Grenze von PSP-, SMM- und Microcode-Ausnutzung trennen.
Ein öffentlicher Proof of Concept muss sorgfältig behandelt werden. Die Veröffentlichung ausreichender Details zur Überprüfung kann auch die Kosten der Bewaffnung gegen nicht unterstützte Systeme senken.
Das zweite Signal ist eine Produkt-Sicherheitsreaktion von AMD. Besitzer benötigen ein Bulletin mit betroffenen Modellen, Schweregrad, Voraussetzungen, Abhilfemaßnahmen und verfügbaren Firmware- oder Microcode-Updates.
AMD hat zuvor fTPM-Hinweise veröffentlicht, die betroffene Firmware-Versionen und Schritte zur Abhilfe getrennt aufführen. Die fTPM guidance zeigt den Grad an Spezifität, der für eine nützliche Reaktion erforderlich ist.
Ein Bulletin würde außerdem klären, ob neuere Familien irgendeinen Teil des Mechanismus geerbt haben. Die aktuelle Berichterstattung beschränkt Skitter auf Family 15h und 16h.
Diese berichtete Begrenzung schließt Zen-basierte Ryzen- und EPYC-Prozessoren aus, sofern spätere Belege den Umfang nicht erweitern. Leser sollten die Behauptung nicht auf alle AMD-CPUs verallgemeinern.
Eine AMD-Stellungnahme könnte die aktuelle Einschätzung abschwächen, falls das Bit unter unterstützten Konfigurationen nicht zugänglich ist. Sie würde sie stärken, falls das Unternehmen eine breite Modellsichtbarkeit bestätigt.
Das dritte Signal ist die Herstellerbehebung für Maschinen, die weiterhin eingesetzt werden. Mainboard-Hersteller und Anbieter von Embedded-Systemen steuern die Firmware-Auslieferung für viele betroffene Produkte.
Eine Korrektur auf Prozessorebene hat nur begrenzten Wert, wenn Gerätebesitzer sie nicht in einem signierten, bereitstellbaren Firmware-Paket erhalten können. Ältere Consumer-Mainboards bergen die größte Support-Unsicherheit.
Embedded-Anbieter könnten längere Verpflichtungen oder Kundennachfrage nach Updates erleben. Ihre Reaktion wird zeigen, wie viele betroffene Plattformen betrieblich weiterhin wichtig sind.
Unternehmen sollten parallel ihre eigene Inventarisierung überwachen. Die Zahl exponierter Maschinen ist wichtiger als das Suchinteresse an amazon amd-Listen.
Sicherheitsteams können mit einer nichtinvasiven Identifizierung beginnen. Sie sollten keine undokumentierten Anweisungen auf Produktionshardware ausführen, solange technische Details noch unvollständig sind.
Beschaffungsteams sollten Systeme der Familien 15h und 16h, die zur Wiederverwendung angeboten werden, kennzeichnen. Ein niedriger Kaufpreis gleicht ein nicht behebbares Problem bei der Hardware-Isolation nicht aus.
Gebrauchte Systeme können weiterhin in kontrollierten Forschungsumgebungen eingesetzt werden. Sie sollten keine sensiblen Aufgaben übernehmen, nur weil ihre Leistung noch ausreicht.
Incident-Response-Teams sollten bei der Untersuchung eines verdächtigen betroffenen Systems die tieferen Ebenen berücksichtigen. Ein unauffälliger Betriebssystem-Scan kann nicht belegen, dass SMM- oder Firmware-Zustand vertrauenswürdig ist.
Auch eine Neuinstallation des Betriebssystems kann nur begrenzte Gewissheit bieten. Entscheidungen zur Wiederherstellung sollten auf bestätigten Details zu Persistenz und beschreibbarem Speicher beruhen.
Für die meisten einzelnen Besitzer besteht kein Anlass zur sofortigen Panik. Die Berichterstattung zeigt weder eine breit angelegte Remote-Kampagne noch eine Kompromittierung von Amazon oder eine automatische Ausnutzung durch gewöhnliches Surfen.
Eine weitere Nutzung verdient dennoch eine genaue Prüfung, wenn das System wichtige Zugangsdaten enthält oder keine Firmware-Unterstützung mehr erhält. Ein Austausch wird zu einer angemessenen Sicherheitsmaßnahme, wenn eine Überprüfung nicht möglich ist.
Der verantwortungsvolle nächste Schritt ist einfach: Identifizieren Sie den Prozessor präzise, achten Sie auf primäre technische Materialien und befolgen Sie modellspezifische Herstellerhinweise. Behandeln Sie Suchergebnisse von Marktplätzen als Anhaltspunkte, nicht als Belege.
Die bleibende Lehre aus Skitter lautet nicht, dass jeder alte AMD-Computer kompromittiert ist. Sie lautet, dass eine winzige architektonische Kontrolle mehr Autorität besitzen kann als mehrere Ebenen sichtbarer Sicherheitssoftware.
Falls Ihr Inventar Hardware der Familien 15h oder 16h enthält: Können Sie heute das genaue Modell, den Firmware-Status und den Zugriff auf sensible Systeme identifizieren?
Dokumentieren Sie diese Antworten, bevor Sie etwas testen. Vergleichen Sie dann jedes Gerät mit den bevorstehenden Offenlegungen von Domas, AMD und dem jeweiligen Mainboard- oder Embedded-System-Anbieter.
Für Leser, die über eine amazon amd search hierher gelangen, bleibt die entscheidende Unterscheidung bestehen. Es handelt sich um ein gemeldetes Problem bei der AMD-Prozessorisolation, nicht um einen bestätigten Sicherheitsvorfall bei Amazon.
