Mikroarchitektonische Sicherheit von AWS Firecracker VMM: Analyse von mikroarchitektonischen Angriffen und Abwehrmaßnahmen

Linktabelle

• Zusammenfassung und Einleitung
• Hintergrund
• Bedrohungsmodelle
• Analyse der Eindämmungssysteme von Feuerwerkskörpern
• Analyse von mikroarchitektonischen Angriffen und Abwehrmaßnahmen in Firecracker-Mikro-VMs
• Schlussfolgerung, Danksagungen und Referenzen

5. ANALYSE VON MIKROARCHITEKTONISCHEN ANGRIFFEN UND VERTEIDIGUNGSMASSNAHMEN IN FIRECRACKER-MIKROVM

In diesem Abschnitt präsentieren wir unsere Analyse einer Reihe von mikroarchitektonischen Side-Channel- und spekulativen Angriffs-PoCs auf Firecracker-Mikro-VMs. Wir testen diese PoCs auf Bare Metal und in Firecracker-Instanzen und testen relevante Mikrocode-Abwehrmaßnahmen in den verschiedenen Szenarien. Wir führen unsere Tests auf einem Server mit einer Intel Skylake 4114-CPU durch.

die Virtualisierungshardwareerweiterungen und SMT aktiviert hat. Die CPU läuft auf der Mikrocodeversion 0x2006b06[2]. Das Host-Betriebssystem ist Ubuntu 20.04 mit einem Linux 5.10-Kernel. Wir haben Firecracker v1.0.0 und v1.4.0, die neueste Version von Juli 2023, verwendet, um einen Ubuntu 18.04-Gast mit Linux-Kernel 5.4 auszuführen, der von Amazon bereitgestellt wird, wenn man der Schnellstartanleitung folgt[3].

Zusammenfassend lässt sich sagen, dass das empfohlene Produktionshost-Setup von AWS Firecracker unzureichend ist, wenn es darum geht, Mandanten vor böswilligen Nachbarn zu schützen. Firecracker kann daher die versprochenen Isolationsgarantien nicht erfüllen. Der Grund hierfür ist, dass

(1) Wir haben eine Medusa-Variante identifiziert, die nur dann ausnutzbar wird, wenn sie auf MicroVMs ausgeführt wird. Darüber hinaus enthalten die empfohlenen Gegenmaßnahmen nicht die notwendigen Schritte, um den Seitenkanalangriff oder die meisten anderen Medusa-Varianten einzudämmen.

(2) Wir zeigen, dass Mieter bei Anwendung der empfohlenen Gegenmaßnahmen nicht ausreichend vor Informationslecks durch Spectre-PHT oder Spectre-BTB geschützt sind. Die Spectre-PHT-Varianten bleiben auch bei Deaktivierung von SMT ein Problem.

(3) Wir haben keine Unterschiede in der PoC-Leistung zwischen Firecracker v1.0.0 und v1.4.0 festgestellt.

Wir kommen zu dem Schluss, dass die von Firecracker bereitgestellte Virtualisierungsschicht wenig Einfluss auf mikroarchitekturale Angriffe hat und die Systemsicherheitsempfehlungen von Firecracker unzureichend sind.

5.1 Medusa

Wir evaluierten Moghimis PoCs [35] für die Medusa [37]-Seitenkanäle (von Intel als MLPDS-Varianten von MDS [25] klassifiziert) auf dem Bare-Metal unseres Testsystems und in Firecracker-VMs. Für jede der drei bekannten Varianten, die in Abschnitt 2.4.2 beschrieben sind, gibt es einen undichten PoC. Wir verwendeten zwei Opferprogramme aus der PoC-Bibliothek:

• Das Programm „Block Write“ schreibt eine große Menge aufeinanderfolgender Daten in einer Schleife (damit der Prozessor wiederholte Speicherungen erkennt und kombiniert).

• Das Programm „REP MOV“ führt eine ähnliche Operation aus, jedoch mit dem REP MOV-Befehl anstelle vieler Befehle, die kleinere Datenblöcke in einer Schleife verschieben.

5.1.1 Ergebnisse. Tabelle 1 zeigt die Fälle, in denen Daten erfolgreich geleakt wurden, obwohl alle mikroarchitektonischen Schutzmaßnahmen im Kernel deaktiviert waren. Die beiden linken Spalten zeigen die möglichen Kombinationen der drei Medusa-PoCs und der beiden enthaltenen Opferprogramme. Die rechten Spalten zeigen, welche Konfigurationen auf Bare Metal und mit dem geheimen und geleakten Programm, das in parallelen Firecracker-Instanzen läuft, funktionieren. Besonders bemerkenswert ist, dass das geheime Block-Write-Programm mit der Cache-Indexing-Variante nur mit Firecracker funktioniert. Dies liegt wahrscheinlich an der Speicheradressvirtualisierung, die die virtuelle Maschine bereitstellt: Der Gast sieht nur virtuelle Speicherbereiche, die von KVM zugeordnet werden, und KVM fängt Speicherzugriffsanweisungen ab und verarbeitet die Transaktionen im Namen des Gasts.

Wir haben die Wirksamkeit der mds- und nosmt-Abwehr gegen jede Kombination aus Angreifer- und Opfer-PoC auf Bare-Metal- und Firecracker-VMs getestet. Tabelle 2 listet die erforderlichen Schutzmaßnahmen auf, um Medusa-Angriffe in Bare-Metal- und Firecracker-Szenarien zu verhindern. Von den vier Sicherheitslücken in Firecracker wird nur eine allein durch nosmt gemildert, und AWS empfiehlt nicht ausdrücklich, den mds-Schutz zu aktivieren, obwohl er bei den meisten Linux-Distributionen standardmäßig aktiviert ist. Das heißt, eine Multi-Tenant-Cloud-Plattform könnte Firecracker auf eine Weise verwenden, die den empfohlenen Sicherheitsmaßnahmen von AWS entspricht, und dennoch für die meisten Medusa-Varianten anfällig sein, einschließlich einer, bei der die Firecracker-VMM selbst die Daten des Benutzers preisgibt, die andernfalls nicht preisgegeben würden.

5.2 RIDL und mehr

In diesem Abschnitt präsentieren wir eine Bewertung der RIDL-PoC-Programme [51], die zusammen mit dem Paper von van Schaik et al. aus dem Jahr 2019 [50] bereitgestellt werden. RIDL ist eine Klasse von MDS-Angriffen, die spekulative Lasten aus Puffern innerhalb der CPU ausnutzt (nicht aus dem Cache oder dem Speicher). Das RIDL-PoC-Repository enthält auch Beispiele für Angriffe, die in späteren Nachträgen zum Paper veröffentlicht wurden, sowie eine Variante des Fallout-MDS-Angriffs.

5.2.1 Ergebnisse. Tabelle 3 zeigt einige grundlegende Informationen zu den von uns getesteten RIDL-PoCs und der Wirksamkeit relevanter Gegenmaßnahmen zur Verhinderung der Angriffe. Wir verglichen Angriffe auf Bare Metal und in Firecracker, um Amazons Behauptungen über die erhöhte Hardwaresicherheit des Firecracker-Mikro-VM-Systems zu überprüfen. Für Tests auf dem Firecracker-System unterscheiden wir zwischen Gegenmaßnahmen-Flags, die auf dem Hostsystem (H) und dem Firecracker-Gastkernel (VM) aktiviert sind. Neben den Kernel-Flags nosmt und mds testeten wir weitere relevante Flags (vgl. Abschnitt 2.4.4, [21]), darunter kaslr, pti und l1tf, konnten jedoch keine Auswirkungen auf eines dieser Programme feststellen. Wir schlossen die tsx_async_abort-Abschwächung aus, da die CPU, auf der wir getestet haben, eine mds-Abschwächung enthält, die das Kernel-Flag tsx_async_abort überflüssig macht [20].

Im Allgemeinen haben wir festgestellt, dass der MDS-Schutz nicht ausreichend vor den meisten RIDL-Angriffen schützt. Das Deaktivieren von SMT schwächt jedoch die meisten dieser Exploits ab. Dies steht im Einklang mit den Aussagen von Intel [25] und den Linux-Entwicklern [21], dass SMT deaktiviert werden muss, um MDS-Angriffe über Hyperthreads hinweg zu verhindern. Die beiden Ausreißer unter diesen PoCs sind alignment_write, das sowohl nosmt als auch mds auf dem Host erfordert, und pgtable_leak_notsx, das nur durch mds-Gegenmaßnahmen gemildert wird. Das auf alignment_write basierende Leck nutzt einen Ausrichtungsfehler anstelle eines Seitentabellenfehlerlecks, um Spekulationen auszulösen [50]. Das RIDL-Papier [50] und Intels Dokumentation des zugehörigen VRS-Exploits [26] sind unklar, was genau diesen Angriff von den auf Seitenfehlern basierenden MFBDS-Angriffen unterscheidet, die in anderen PoCs gefunden wurden, aber unsere experimentellen Ergebnisse deuten darauf hin, dass der mikroarchitektonische Mechanismus des Lecks anders ist. Es gibt eine einfache und vernünftige Erklärung für das Verhalten von pgtable_leak_notsx, das aus einem wichtigen Grund unter diesen PoCs einzigartig ist: Es ist der einzige Exploit, der Sicherheitsgrenzen überschreitet (Seitentabellenwerte aus dem Kernel durchsickern lässt) und zwar innerhalb eines einzelnen Threads, anstatt aus einem anderen Thread durchsickern zu lassen. Es ist offensichtlich, dass das Deaktivieren von Multithreading nur geringe Auswirkungen auf diesen Single-Thread-Exploit hätte. Die MDS-Gegenmaßnahme leert jedoch die mikroarchitektonischen Puffer, bevor sie innerhalb desselben Threads von der Ausführung mit Kernelprivilegien zur Ausführung mit Benutzerprivilegien wechselt, und löscht die Seitentabellendaten, auf die der Kernelcode aus dem LFB zugreift, bevor der angreifende Benutzercode sie durchsickern lassen kann.

Im Gegensatz zu Medusa werden die meisten dieser PoCs durch die AWS-Empfehlung, smt zu deaktivieren, abgeschwächt. Wie bei Medusa bietet das Firecracker VMM selbst jedoch keinen mikroarchitektonischen Schutz gegen diese Angriffe.

5.3 Gespenst

Als nächstes konzentrieren wir uns auf die Spectre-Schwachstellen. Seit der Entdeckung der Spectre-Angriffe wurden zwar viele Gegenmaßnahmen entwickelt, doch viele davon sind entweder mit (erheblichen) Leistungseinbußen verbunden oder mildern den Angriff nur teilweise. Daher

Systembetreiber müssen sich häufig zwischen Leistung und Sicherheit entscheiden. In diesem Abschnitt bewerten wir die Spectre-Angriffsfläche, die Firecracker-Tenants in beiden zuvor beschriebenen Bedrohungsmodellen zur Verfügung steht. Um die große Bandbreite an Spectre-Angriffen zu bewerten, stützen wir uns auf die in [15] bereitgestellten PoCs. Für Spectre-PHT, Spectre-BTB und SpectreRSB enthält das Repository jeweils vier PoCs. Sie unterscheiden sich in der Art und Weise, wie der Angreifer die BPU fehltrainiert. Die vier Möglichkeiten sind: (1) Gleicher Prozess – der Angreifer hat Kontrolle über den Opferprozess oder dessen Eingaben, um die BPU falsch zu trainieren – (2) Prozessübergreifend – der Angreifer führt seinen eigenen Code in einem separaten Prozess aus, um die Verzweigungsvorhersagen des Opferprozesses zu beeinflussen – (a) Vor-Ort – der Angreifer trainiert die BPU falsch mit Verzweigungsanweisungen, die an derselben virtuellen Adresse liegen wie der Zielzweig, den der Angreifer im Opferprozess falsch vorhersagen möchte – (b) Außerhalb des Ortes – der Angreifer trainiert die BPU falsch mit Verzweigungsanweisungen, die an Adressen liegen, die mit den Zielzweigen im Opferprozess übereinstimmen.

(1) Same-Process: Der Angreifer hat die Kontrolle über den Opferprozess oder dessen Eingaben, um die BPU zu manipulieren,

(2) prozessübergreifend: Der Angreifer führt seinen eigenen Code in einem separaten Prozess aus, um die Verzweigungsvorhersagen des Opferprozesses zu beeinflussen.

(3) in-place: Der Angreifer manipuliert die BPU mit Verzweigungsanweisungen, die sich an derselben virtuellen Adresse befinden wie der Zielzweig, den der Angreifer im Opferprozess falsch vorhersagen möchte.

(4) Out-of-Place: Der Angreifer manipuliert die BPU mit Verzweigungsanweisungen, die an Adressen liegen, die mit den Zielverzweigungen im Opferprozess übereinstimmen.

Die ersten beiden und die letzten beiden Situationen sind orthogonal, sodass jeder PoC zwei davon kombiniert. Für Spectre-STL sind nur Varianten mit demselben Prozess bekannt, weshalb das Repository in diesem Fall nur zwei PoCs bereitstellt. Für Cross-VM-Experimente wurde die Randomisierung des Adressraumlayouts für die Host- und Gastkernel sowie für die Host- und Gastbenutzerebene deaktiviert, um das Auffinden kongruenter Adressen zu erleichtern, die für Fehltraining verwendet werden.

5.3.1 Ergebnisse. Mit den von AWS empfohlenen Gegenmaßnahmen [8] (die Standardvorgabe für die verwendeten Linux-Kernel, siehe Abbildung 5) auf dem Hostsystem und in Firecracker-VMs sehen wir, dass Spectre-RSB sowohl auf dem Host als auch innerhalb und zwischen VMs erfolgreich abgeschwächt wird (siehe Tabelle 4). Auf der anderen Seite ermöglichten Spectre-STL, Spectre-BTB und Spectre-PHT in bestimmten Situationen Informationslecks.

Die PoCs für Spectre-STL zeigen Lecks. Allerdings treten die Lecks nur innerhalb desselben Prozesses und derselben Berechtigungsstufe auf. Da keine prozessübergreifenden Varianten bekannt sind, haben wir das Cross-VM-Szenario für Spectre-STL nicht getestet. In unserem Benutzer-zu-Benutzer-Bedrohungsmodell ist Spectre-STL kein möglicher Angriffsvektor, da keine prozessübergreifenden Varianten bekannt sind. Wenn zwei Mandanten-Workloads durch In-Process-Isolation innerhalb derselben VM isoliert würden, könnte Spectre-STL immer noch ein praktikabler Angriffsvektor sein. Im Benutzer-zu-Host-Modell wird Spectre-STL durch Gegenmaßnahmen abgeschwächt, die in aktuellen Linux-Kerneln enthalten und standardmäßig aktiviert sind.

Für Spectre-PHT umfassen die Kernel-Gegenmaßnahmen die Bereinigung von Benutzerzeigern und die Verwendung von Barrieren (lfence) bei Berechtigungsstufenwechseln. Wir kommen daher zu dem Schluss, dass SpectrePHT kaum oder gar keine Bedrohung für das Hostsystem darstellt. Diese

Die Abwehrmaßnahmen schützen zwei Hyperthreads nicht voreinander, wenn sie parallel auf demselben physischen Kern ausgeführt werden. Aus diesem Grund sind alle vier Spectre-PHT-Misstraining-Varianten sowohl auf dem Hostsystem als auch in Firecracker-VMs voll funktionsfähig. Wie aus Tabelle 4 hervorgeht, gilt dies auch dann, wenn SMT deaktiviert ist[4]. Tatsächlich aktiviert das Fixieren beider VMs auf denselben physischen Thread die prozessübergreifende Out-of-Place-Version von Spectre-PHT, während wir im SMT-Fall keine Lecks beobachtet haben. Dies macht Spectre-PHT zu einer erheblichen Bedrohung für Benutzer-zu-Benutzer.

Spectre-BTB PoCs sind teilweise funktionsfähig, wenn von AWS empfohlene Gegenmaßnahmen aktiviert sind. Die ursprüngliche Variante, die das BTB im selben Prozess und an derselben Adresse falsch trainiert, ist voll funktionsfähig, während das falsche Training im selben Prozess nicht funktioniert.

erfolgreich gemildert. Auch alle Versuche, Informationen über Prozessgrenzen hinweg durch Out-of-Place-Fehltraining zu leaken, zeigten keine Lecks. Bei prozessübergreifendem In-Place-Fehltraining konnten wir jedoch Lecks beobachten. Auf dem Hostsystem trat das Leck unabhängig von SMT auf. Innerhalb einer VM trat das Leck nur auf, wenn alle virtuellen CPU-Kerne einem separaten physischen Thread zugewiesen waren. Über VMs hinweg wurde das Leck durch das Deaktivieren von SMT behoben.

Neben den in Abbildung 5 aufgelisteten Gegenmaßnahmen verfügt der Host-Kernel über Spectre-Gegenmaßnahmen, die in den VM-Einstiegs- und -Ausstiegspunkt[5] kompiliert sind, um böswillige Gäste vollständig daran zu hindern, den Host-Kernel anzugreifen, während der Kernel einen VM-Ausgang verarbeitet.

Zusammenfassend lässt sich sagen, dass die von AWS Firecracker empfohlenen Linux-Standardmaßnahmen Spectre nur teilweise abschwächen. Konkret zeigen wir:

• Spectre-PHT und Spectre-BTB können im Gast-zu-Gast-Szenario immer noch Informationen zwischen Mandanten weitergeben, wenn die von AWS empfohlenen Gegenmaßnahmen – darunter die Deaktivierung von SMT – vorhanden sind.

• Der Host-Kernel ist wahrscheinlich durch die zusätzlichen Vorkehrungen, die in den Linux-Kernel kompiliert sind, um VM-Ein- und Ausgänge abzuschirmen, ausreichend geschützt. Dies steht jedoch im Widerspruch zu den Sicherheitsmaßnahmen von Firecracker.

Alle beobachteten Leckagen waren unabhängig von der verwendeten Firecracker-Version.

5.3.2 Bewertung. Wir stellen fest, dass Firecracker die Abwehrmaßnahmen gegen Spectre nicht ergänzt, sondern sich ausschließlich auf allgemeine Schutzempfehlungen verlässt, die Abwehrmaßnahmen der Host- und Gastkernel sowie optionale Mikrocode-Updates umfassen. Schlimmer noch: Die empfohlenen Gegenmaßnahmen schützen serverlose Anwendungen unzureichend vor der Weitergabe von Informationen an andere Mandanten. Wir behaupten daher, dass Firecracker sein Isolationsziel auf mikroarchitektonischer Ebene nicht erreicht, obwohl mikroarchitektonische Angriffe als im Rahmen des Firecracker-Bedrohungsmodells liegend betrachtet werden.

Der aufmerksame Leser mag sich fragen, warum Spectre-BTB trotz der STIBP-Gegenmaßnahme (vgl. Abbildung 5) weiterhin ein Problem darstellt, da dieser Microcode-Patch dafür entwickelt wurde, die Verzweigungsvorhersage daran zu hindern, Vorhersageinformationen zu verwenden, die aus einem anderen Thread stammen. Auch wir haben uns eine Zeit lang darüber gewundert, bis Google vor Kurzem eine Sicherheitswarnung[6] veröffentlichte, die einen Fehler in Linux 6.2 identifiziert, der die STIBP-Abschwächung immer wieder deaktiviert, wenn IBRS aktiviert ist. Wir haben überprüft, dass der Codeabschnitt, der als für das Problem verantwortlich identifiziert wurde, auch im Quellcode von Linux 5.10 vorhanden ist. Wir gehen daher davon aus, dass das von Google identifizierte Problem auch auf unserem System auftritt.

[2] Das Aktualisieren des Mikrocodes auf eine neuere Version würde TSX auf unserem System deaktivieren, was Tests mit TSX-basierten MDS-Varianten unmöglich machen würde.

[3] https://github.com/firecracker-microvm/firecracker/blob/ dbd9a84b11a63b5e5bf201e244fe83f0bc76792a/docs/getting-started.md

[4] Dies wird dadurch simuliert, dass Angreifer- und Opferprozess auf den gleichen Kern fixiert werden ((1PT))

[5] https://elixir.bootlin.com/linux/v5.10/source/arch/x86/kvm/vmx/vmenter.S#L191

[6] https://github.com/google/security-research/security/advisories/GHSA-mj4w6495-6crx