Autoren:  (1) Zane Weissman, Worcester Polytechnic Institute Worcester, MA, USA {zweissman@wpi.edu};  (2) Thomas Eisenbarth, Universität zu Lübeck Lübeck, SH, Deutschland {thomas.eisenbarth@uni-luebeck.de};  (3) Thore Tiemann, Universität zu Lübeck Lübeck, SH, Deutschland {t.tiemann@uni-luebeck.de};  (4) Berk Sunar, Worcester Polytechnic Institute Worcester, MA, USA {sunar@wpi.edu}.  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.     . 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. KVM    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. Metadaten-, Geräte- und E/A-Dienste.  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.    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]. Jailer-Barriere.  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.  Dieses Dokument ist   . auf arxiv unter der Lizenz CC BY-NC-ND 4.0 DEED verfügbar

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

AutoEncoder.tech

Research & publications on Auto Encoders, revolutionizing data compression and feature learning techniques.

Auto Encoder's blog

Dieses Audio ist in der Originalsprache der Geschichte produziert!

Zu lang; Lesen

Boost your HackerNoon story @ $159.99! 🚀

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

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

HackerNoon Decoded 2024: Wir feiern die Community unserer Technologieunternehmen!

HackerNoon Decoded 2024: Wir feiern unsere Produktmanagement-Community!

HackerNoon Decoded 2024: Celebrating Our Cybersecurity Community!

HackerNoon Decoded 2024: Celebrating Our AI Community!

HackerNoon Decoded 2024: Wir feiern die Community unserer Technologieunternehmen!

HackerNoon Decoded 2024: Wir feiern unsere Produktmanagement-Community!

HackerNoon Decoded 2024: Celebrating Our Cybersecurity Community!

HackerNoon Decoded 2024: Celebrating Our AI Community!

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps