APIC/EPISCH! Intel-Chips geben Geheimnisse preis, die selbst der Kernel nicht sehen sollte …

Hier ist das BWAIN dieser Woche, unser scherzhafter Begriff für a Fehler mit einem beeindruckenden Namen.

BWAIN ist eine Auszeichnung, die wir vergeben, wenn sich eine neue Cybersicherheitslücke nicht nur als interessant und wichtig herausstellt, sondern auch mit eigenem Logo, Domainnamen und Website auftaucht.

Dieser ist synchronisiert ÆPIC-Leck, ein Wortspiel mit den Worten APIC und EPIC.

Ersteres ist die Abkürzung für Fortschrittlicher programmierbarer Interrupt-Controller, und letzteres ist einfach das Wort „episch“, wie in Riese, massiv, Extrem, Mega-, gigantisch.

Der Buchstabe Æ wird seit sächsischer Zeit nicht mehr im geschriebenen Englisch verwendet. Sein Name ist äsc, ausgesprochen Asche (wie im Baum), und es repräsentiert ziemlich genau den Klang des A in im modernen Wort ASH. Aber wir gehen davon aus, dass Sie das Wort aussprechen sollen ÆPIC hier entweder als „APIC-slash-EPIC“, oder als „ah!-eh?-PIC“.

Worum geht es?

All dies wirft fünf spannende Fragen auf:

• Was ist ein APIC, und warum brauche ich es?
• Wie können Sie Daten haben, die sogar der Kern kann nicht gucken?
• Was verursacht dieses epische Scheitern im APIC?
• Hat das ÆPIC-Leck betrifft mich?
• Was ist zu tun darüber?

Was ist ein APIC?

Spulen wir zurück ins Jahr 1981, als der IBM-PC zum ersten Mal auf den Markt kam.

Der PC enthielt einen Chip namens the Programmierbarer Interrupt-Controller Intel 8259A, oder PIC. (Spätere Modelle, ab dem PC AT, hatten zwei PICs, die miteinander verkettet waren, um mehr Interrupt-Ereignisse zu unterstützen.)

Der Zweck des PIC bestand buchstäblich darin, das auf dem zentralen Prozessor (CPU) des PCs laufende Programm zu unterbrechen, wenn etwas Zeitkritisches passierte, das sofort erledigt werden musste.

Diese Hardware-Interrupts umfassten Ereignisse wie: die Tastatur erhält einen Tastendruck; der serielle Port empfängt ein Zeichen; und ein sich wiederholender Hardware-Timer, der überläuft.

Ohne ein Hardware-Interrupt-System dieser Art müsste das Betriebssystem mit Funktionsaufrufen übersät sein, um regelmäßig nach eingehenden Tastenanschlägen zu suchen, was eine Verschwendung von CPU-Leistung wäre, wenn niemand tippt, aber nicht reagiert genug, wenn sie es taten.

Wie Sie sich vorstellen können, folgte dem PIC bald ein verbesserter Chip namens the APIC, ein advanced Art von PIC in die CPU selbst eingebaut.

Heutzutage bieten APICs viel mehr als nur Feedback von der Tastatur, dem seriellen Anschluss und dem Systemtimer.

APIC-Ereignisse werden durch Ereignisse wie Überhitzung ausgelöst (und liefern Echtzeitdaten darüber) und ermöglichen eine Hardware-Interaktion zwischen den verschiedenen Kernen in modernen Multicore-Prozessoren.

Und die heutigen Intel-Chips können, wenn wir stark vereinfachen dürfen, im Allgemeinen so konfiguriert werden, dass sie auf zwei verschiedene Arten funktionieren, die als bekannt sind xAPIC-Modus und x2APIC-Modus.

Hier xAPIC ist die „alte“ Art, Daten aus dem Interrupt-Controller zu extrahieren, und x2APIC ist der modernere Weg.

Um es noch weiter zu vereinfachen, stützt sich xAPIC auf das, was aufgerufen wird MMIO, kurz für speicherabgebildete Ein-/Ausgabe, zum Auslesen von Daten aus dem APIC, wenn es ein interessierendes Ereignis registriert.

Im MMIO-Modus können Sie herausfinden, was ein APIC-Ereignis ausgelöst hat, indem Sie aus einem bestimmten Speicherbereich (RAM) lesen, der die Ein-/Ausgangsregister des APIC-Chips selbst widerspiegelt.

Diese xAPIC-Daten werden irgendwo im physischen RAM des Computers in einen 4096-Byte-Speicherblock abgebildet.

Dies vereinfacht den Zugriff auf die Daten, erfordert jedoch eine lästige, komplexe (und, wie wir sehen werden, potenziell gefährliche) Interaktion zwischen dem APIC-Chip und dem Systemspeicher.

Im Gegensatz dazu erfordert x2APIC, dass Sie dies tun die APIC-Daten direkt auslesen aus dem Chip selbst, unter Verwendung von sogenannten Modellspezifische Register (MSR).

Laut Intel wird der MMIO-Teil des Prozesses vermieden „Bietet eine deutlich verbesserte Adressierbarkeit des Prozessors und einige Verbesserungen bei der Interrupt-Zustellung.“

Das Extrahieren der APIC-Daten direkt aus On-Chip-Registern bedeutet insbesondere, dass die Gesamtmenge der unterstützten Daten und die maximale Anzahl der CPU-Kerne, die gleichzeitig verwaltet werden können, nicht auf die im MMIO-Modus verfügbaren 4096 Bytes beschränkt sind.

Wie können Sie Daten haben, die nicht einmal der Kernel sehen kann?

Sie haben wahrscheinlich schon erraten, dass die Daten, die im xAPIC-Modus im MMIO-Speicherbereich landen, nicht immer so sorgfältig verwaltet werden, wie es sein sollte …

… und daher ist diese Art von „Datenleck“ in diesen MMIO-Bereich der Kern dieses Problems.

Aber vorausgesetzt, Sie benötigen bereits Befugnisse auf Sysadmin-Ebene um die MMIO-Daten überhaupt zu lesen, und daher könnten Sie mit ziemlicher Sicherheit sowieso an alle Daten im Speicher gelangen …

…warum sollte das versehentliche Auftauchen von Daten anderer Personen im APIC MMIO-Datenbereich eine Epos Leck?

Es könnte einige Arten von Datendiebstahl- oder RAM-Scraping-Angriffen in der Praxis etwas einfacher machen, aber es würde Ihnen sicherlich nicht mehr Speicher-Snooping-Fähigkeiten geben, die Sie bereits in der Theorie hatten?

Leider trifft diese Annahme nicht zu, wenn irgendeine Software auf dem System Intels SGX, kurz für, verwendet Software Guard-Erweiterungen.

---

ERFAHREN SIE MEHR ÜBER SGX

---

SGX wird von vielen neueren Intel-CPUs unterstützt und bietet dem Betriebssystemkern eine Möglichkeit, einen Code- und Datenblock in einem physischen RAM-Block zu „versiegeln“, um so eine sogenannte Enklave zu bilden.

Dadurch verhält es sich zumindest vorübergehend ähnlich wie die speziellen Sicherheitschips in Mobiltelefonen, die zum Speichern von Geheimnissen wie Entschlüsselungsschlüsseln verwendet werden.

Sobald die SGX-"Sperre" der Enklave gesetzt ist, kann nur Programmcode, der innerhalb des versiegelten Speicherbereichs läuft, die Inhalte dieses RAM lesen und schreiben.

Infolgedessen sind die internen Details aller Berechnungen, die nach der Aktivierung der Enklave stattfinden, für jeden anderen Code, Thread, Prozess oder Benutzer auf dem System unsichtbar.

Einschließlich des Kernels selbst.

Es gibt eine Möglichkeit, den Code aufzurufen, der in der Enklave versiegelt wurde, und eine Möglichkeit, die Ausgabe der Berechnungen zurückzugeben, die sie möglicherweise durchführt, aber es gibt keine Möglichkeit, den Code wiederherzustellen, auszuspionieren oder zu debuggen und seine zugehörigen Daten, während es läuft.

Die Enklave verwandelt sich effektiv in eine Blackbox, in die Sie Eingaben einspeisen können, z. B. Daten, die mit einem privaten Schlüssel signiert werden sollen, und Ausgaben extrahieren können, z. B. die generierte digitale Signatur, aus der Sie jedoch die kryptografischen Schlüssel nicht herauswinken können im Signierprozess verwendet.

Wie Sie sich vorstellen können, sollten Daten, die in einer SGX-Enklave versiegelt werden sollen, jemals versehentlich in den MMIO-RAM dupliziert werden, der zum „Spiegeln“ der APIC-Daten verwendet wird, wenn Sie den xAPIC-„Memory-Mapped“-Modus verwenden …

…das würde die Sicherheit von SGX verletzen, die besagt, dass keine Daten jemals aus einer SGX-Enklave herauskommen sollten, nachdem sie erstellt wurde, es sei denn, sie werden absichtlich durch Code exportiert, der bereits innerhalb der Enklave selbst läuft.

Was verursacht diesen epischen Fehler in APIC?

Die Forscher hinter der ÆPIC Leckpapier entdeckten, dass durch das Auslesen von APIC-Daten über eine schlaue und ungewöhnliche Folge von Speicherzugriffen …

… sie könnten den Prozessor dazu verleiten, den APIC-MMIO-Speicherplatz nicht nur mit Daten zu füllen, die frisch vom APIC selbst empfangen wurden, sondern auch mit Daten, die zufällig kürzlich von der CPU für einen anderen Zweck verwendet wurden.

Dieses Verhalten ist ein Nebeneffekt der Tatsache, dass die APIC-MMIO-Speicherseite zwar 4096 Byte groß ist, der APIC-Chip im xAPIC-Modus jedoch keine Daten im Wert von 4096 Byte produziert und die CPU nicht immer korrekt neutralisiert die ungenutzten Teile des MMIO-Bereichs, indem Sie ihn zuerst mit Nullen füllen.

Stattdessen wurden im CPU-Cache verbliebene alte Daten zusammen mit den vom APIC-Chip selbst empfangenen neuen Daten herausgeschrieben.

Wie die Forscher es ausdrückten, läuft der Fehler auf das hinaus, was als bekannt ist nicht initialisierter Speicher gelesen, wo Sie versehentlich die übrig gebliebenen Daten einer anderen Person im RAM wiederverwenden, weil weder sie noch Sie sie zuerst von ihren vorherigen Geheimnissen befreit haben.

Betrifft mich der ÆPIC Leak?

Eine vollständige Liste der betroffenen Chips finden Sie unter Intels eigener Ratgeber.

Soweit wir das beurteilen können, sind Sie wahrscheinlich betroffen, wenn Sie einen Intel-Prozessor der 10. oder 11. Generation haben.

Aber wenn Sie eine brandneue CPU der 12. Generation haben (die allerneueste zum Zeitpunkt des Schreibens), dann scheinen nur Chips der Serverklasse betroffen zu sein.

Ironischerweise hat Intel bei Laptop-Chips der 12. Generation SGX aufgegeben, sodass dieser Fehler nicht zutrifft, da es unmöglich ist, „versiegelte“ SGX-Enklaven zu haben, die auslaufen könnten.

Selbst auf einem potenziell anfälligen Chip tritt der Fehler natürlich auch nicht auf, wenn Sie sich nicht auf eine Software verlassen, die SGX verwendet.

Und der Fehler, synchronisiert CVE-2022-21233, kann nur von einem Angreifer ausgenutzt werden, der bereits lokalen Zugriff auf Administratorebene (Root) auf Ihren Computer hat.

Regelmäßige Benutzer können nicht auf den APIC-MMIO-Datenblock zugreifen und haben daher keine Möglichkeit, dort überhaupt etwas zu sehen, ganz zu schweigen von geheimen Daten, die möglicherweise aus einer SGX-Enklave durchgesickert sind.

Ebenfalls, virtuelle Gastmaschinen (VMs), die unter der Kontrolle eines Host-Betriebssystems in einem Hypervisor wie HyperV, VMWare oder VirtualBox laufen, können diesen Trick mit ziemlicher Sicherheit nicht anwenden, um Geheimnisse von anderen Gästen oder dem Host selbst zu plündern.

Das liegt daran, dass Gast-VMs im Allgemeinen keinen Zugriff auf die echten APIC-Schaltkreise im Host-Prozessor erhalten; Stattdessen erhält jeder Gast seinen eigenen simulierten APIC, der für diese VM einzigartig ist.

Was ist zu tun?

Keine Panik.

Auf einem Laptop oder Desktop-Computer sind Sie möglicherweise überhaupt nicht gefährdet, entweder weil Sie einen älteren (oder zum Glück einen brandneuen!) Computer haben oder weil Sie sich sowieso nicht auf SGX verlassen.

Und selbst wenn Sie ein Risiko eingehen, hat jeder, der als Administrator/Root auf Ihren Laptop zugreift, wahrscheinlich genug Macht, um Ihnen bereits eine Menge Ärger zu bereiten.

Wenn Sie anfällige Server haben und sich auf SGX als Teil Ihrer Betriebssicherheit verlassen, sehen Sie sich die Sicherheitsempfehlung von Intel an INTEL-SA-00657 für Schutz- und Minderungsinformationen.

Laut den Forschern, die dies geschrieben haben, „Intel [hat] Microcode- und SGX Software Development Kit-Updates veröffentlicht, um das Problem zu beheben.“

Das Linux-Kernel-Team scheint auch gerade an einem Patch zu arbeiten, mit dem Sie Ihr System so konfigurieren können, dass es immer x2APIC verwendet (das, wie Sie sich von früher erinnern, keine APIC-Daten über Shared Memory überträgt). und verhindert auf elegante Weise, dass das System nach dem Booten wieder in den xAPIC-Modus gezwungen wird.

---