Mikroarchitektonische Sicherheit von AWS Firecracker VMM: Analyse der Eindämmungssysteme von Firecracker

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

4. ANALYSE DER EINSCHRÄNKUNGSSYSTEME FÜR BRANDKÖRPER

Abbildung 2 zeigt die von AWS bereitgestellte Eindämmung durch Firecracker. In diesem Abschnitt analysieren wir jede abgebildete Komponente und ihre Abwehrmaßnahmen und Schwachstellen gegenüber mikroarchitektonischen Angriffen.

KVM . Die Linux kernel-based virtual machine (KVM) ist der Hypervisor, der in modernen Linux-Kerneln implementiert ist und daher Teil der Linux-Codebasis. Sie virtualisiert die Supervisor- und Benutzermodi der zugrunde liegenden Hardware, verwaltet Kontextwechsel zwischen VMs und behandelt die meisten VM-Beendigungsgründe, sofern sie nicht mit E/A-Operationen zusammenhängen. Neben diesen architektonischen Isolationsmechanismen implementiert KVM auch Abwehrmaßnahmen gegen Spectre-Angriffe beim Beenden einer VM, um das Host-Betriebssystem oder den Hypervisor vor böswilligen Gästen zu schützen. Firecracker verlässt sich stark auf KVM als Hypervisor. Da KVM jedoch Teil des Linux-Quellcodes ist und von der Linux-Community entwickelt wurde, definieren wir KVM als keinen Teil von Firecracker. Daher können Gegenmaßnahmen gegen mikroarchitektonische Angriffe, die in KVM implementiert sind, nicht dem Eindämmungssystem von Firecracker zugeschrieben werden.

Metadaten-, Geräte- und E/A-Dienste. Die Metadaten-, Geräte- und E/A-Dienste sind die Teile des Firecracker VMM und der API, die direkt mit einer VM interagieren, Metriken sammeln und verwalten und Konnektivität bereitstellen. AWS wirbt mit der Einfachheit dieser Schnittstellen (für eine reduzierte Angriffsfläche) und damit, dass sie von Grund auf für Firecracker in Rust geschrieben wurden, einer Programmiersprache, die für ihre Sicherheitsfunktionen bekannt ist [9]. Rust bietet jedoch vor allem prozessinternen Schutz vor ungültigen und außerhalb der Grenzen liegenden Speicherzugriffen, aber mikroarchitektonische Angriffe wie Cache-Angriffe, Spectre und MDS können Informationen zwischen Prozessen durchsickern lassen, anstatt den Prozess eines Opfers direkt zu kapern.

Ein weiterer bemerkenswerter Unterschied zwischen Firecracker und vielen anderen VMMs besteht darin, dass alle diese Dienste im selben Hostprozess wie die VM selbst ausgeführt werden, wenn auch in einem anderen Thread. Während die Virtualisierung von Speicheradressen innerhalb der VM eine gewisse Verschleierung zwischen dem Code des Gastes und den E/A-Diensten ermöglicht, funktionieren einige Spectre-Angriffe speziell innerhalb eines einzelnen Prozesses. Intraprozessangriffe stellen jedoch möglicherweise eine geringere Bedrohung für reale Systeme dar, da zwei Gäste, die auf derselben Hardware ausgeführt werden, jeweils über eine eigene Kopie dieser wesentlichen Dienste verfügen.

Jailer-Barriere. Für den Fall, dass die API oder VMM kompromittiert werden, bildet der Jailer eine letzte Verteidigungsbarriere um eine Firecracker-Instanz. Er schützt die Dateien und Ressourcen des Hostsystems mit Namespaces bzw. Kontrollgruppen (cgroups) [7]. Mikroarchitektur-Angriffe bedrohen Dateien nicht direkt, da diese sich per Definition außerhalb des mikroarchitekturalen Zustands befinden. Cgroups ermöglichen es einem Systemadministrator, Prozesse Gruppen zuzuordnen und dann die Nutzung der Systemressourcen pro Gruppe zuzuordnen, einzuschränken und zu überwachen [17]. Es ist plausibel, dass mit cgroups angewendete Beschränkungen die Fähigkeit eines Angreifers beeinträchtigen könnten, bestimmte mikroarchitekturale Angriffe durchzuführen. Beispielsweise könnten Speicherbeschränkungen die Durchführung von Cache-Angriffen auf Basis von Auslagerungen erschweren, oder CPU-Zeitbeschränkungen könnten einen Angreifer daran hindern, ein CPU-Denial-of-Service-Tool wie HyperDegrade [2] effektiv zu nutzen, das einen Opferprozess verlangsamen und so das Timing einer mikroarchitekturalen Seitenkanal-Exfiltration oder -Injektion vereinfachen kann. In der Praxis wird Firecracker nicht mit bestimmten Cgroup-Regeln ausgeliefert [7]. Vielmehr ist es speziell auf den effizienten Betrieb vieler Firecracker-VMs unter der Standard-Ressourcenzuweisung von Linux ausgelegt [6].

Keines der Isolations- und Eindämmungssysteme in Firecracker scheint direkt vor Angriffen von Benutzer zu Benutzer oder von Benutzer zu Host zu schützen. Daher haben wir verschiedene Proof of Concepts für mikroarchitektonische Angriffe innerhalb und außerhalb von Firecracker-VMs getestet.