Mikroarchitektonische Sicherheit von AWS Firecracker VMM: Zusammenfassung und Einführung

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

ABSTRAKT

Firecracker ist ein Virtual Machine Manager (VMM), der von Amazon Web Services (AWS) speziell für serverlose Cloud-Plattformen entwickelt wurde – Dienste, die Code für Endbenutzer auf Task-Basis ausführen und die Serverinfrastruktur automatisch verwalten. Firecracker bietet schnelle und leichte VMs und verspricht eine Kombination aus der Geschwindigkeit von Containern, die normalerweise zur Isolierung kleiner Aufgaben verwendet werden, und der Sicherheit von VMs, die tendenziell eine stärkere Isolierung auf Kosten der Leistung bieten. Diese Kombination aus Sicherheit und Effizienz macht es laut AWS nicht nur möglich, sondern auch sicher, Tausende von Benutzeraufgaben von verschiedenen Benutzern auf derselben Hardware auszuführen, wobei das Hostsystem schnell und häufig zwischen aktiven Aufgaben wechselt. Obwohl AWS angibt, dass mikroarchitektonische Angriffe in ihrem Bedrohungsmodell enthalten sind, basiert diese Angriffsklasse direkt auf gemeinsam genutzter Hardware, genau wie die Skalierbarkeit des serverlosen Computing auf der gemeinsamen Nutzung von Hardware durch eine beispiellose Anzahl von Benutzern beruht.

In dieser Arbeit untersuchen wir, wie sicher Firecracker gegen mikroarchitektonische Angriffe ist. Zunächst überprüfen wir das angegebene Isolationsmodell und die empfohlenen Best Practices für die Bereitstellung von Firecracker, identifizieren potenzielle Bedrohungsmodelle für serverlose Plattformen und analysieren potenzielle Schwachstellen. Dann verwenden wir Proof-of-Concepts für mikroarchitektonische Angriffe, um die von Firecracker bereitgestellte Isolation zu testen, und stellen fest, dass sie wenig Schutz gegen Spectre- oder MDS-Angriffe bietet. Wir entdecken zwei besonders besorgniserregende Fälle: 1) eine Medusa-Variante, die Firecracker-VMs bedroht, aber keine Prozesse, die außerhalb dieser laufen, und die nicht durch von AWS empfohlene Abwehrmaßnahmen abgeschwächt wird, und 2) eine Spectre-PHT-Variante, die auch dann ausnutzbar bleibt, wenn empfohlene Gegenmaßnahmen vorhanden sind und SMT im System deaktiviert ist. Zusammenfassend zeigen wir, dass AWS die dem Firecracker-VMM innewohnende Sicherheit überbewertet und unvollständige Anleitungen für die ordnungsgemäße Sicherung von Cloud-Systemen bietet, die Firecracker verwenden.

CCS-KONZEPTE

• Sicherheit und Datenschutz → Virtualisierung und Sicherheit; Sidechannel-Analyse und Gegenmaßnahmen.

SCHLÜSSELWÖRTER

Systemsicherheit, mikroarchitektonische Sicherheit, virtuelle Maschinen, Hypervisor, Serverless, Cloud-Systeme

1. EINLEITUNG

Serverloses Computing ist ein neuer Trend im Cloud-Computing, bei dem Cloud-Service-Provider (CSPs) ihren Kunden Laufzeitumgebungen bereitstellen. Auf diese Weise können sich die Kunden auf die Wartung ihres Funktionscodes konzentrieren und die Verwaltungsarbeit in Bezug auf Hardware, Betriebssystem (OS) und manchmal auch Laufzeit den CSPs überlassen. Zu den gängigen serverlosen Plattformmodellen gehören Function-as-a-Service (FaaS) und Container-as-a-Service (CaaS). Da einzelne Funktionen in der Regel klein sind, die Anwendungen der Kunden jedoch jeweils zwischen einer und Tausenden von Funktionen ausführen können, versuchen CSPs, so viele Funktionen wie möglich auf einem einzigen Server unterzubringen, um Leerlaufzeiten zu minimieren und so den Gewinn zu maximieren. Ein eher einfacher Ansatz zur Bereitstellung von Laufzeitumgebungen besteht darin, Container auszuführen, die einen Prozess mit seinen Abhängigkeiten kapseln, sodass nur die erforderlichen Dateien für jeden Prozess in virtuelle Dateisysteme auf einem gemeinsamen Kernel geladen werden. Dadurch wird ein Wechsel zwischen Containern auf kaum mehr als einen Kontextwechsel zwischen Prozessen reduziert. Auf der anderen Seite bietet die vollständige Virtualisierung eine gute Isolierung zwischen virtuellen Maschinen (VMs) und damit Sicherheit zwischen Mandanten, ist jedoch ziemlich schwergewichtig, da jede VM mit ihrem eigenen Kernel ausgestattet ist.

Keiner dieser Ansätze, Container oder VM, ist ideal für den Einsatz in serverlosen Umgebungen, in denen idealerweise viele kurzlebige Funktionen, die vielen Benutzern gehören, gleichzeitig ausgeführt werden und häufig wechseln, sodass für diesen Anwendungsfall neue Isolationsmechanismen entwickelt wurden. Beispielsweise sollen Mechanismen zur In-Process-Isolation [38, 45, 49] die Sicherheit von Containern verbessern, indem sie die Angriffsfläche der Laufzeit und des zugrunde liegenden Kernels reduzieren. Der Schutz des Kernels ist wichtig, da ein kompromittierter Kernel im Containerfall direkt zu einem vollständig kompromittierten System führt. Bestimmte leistungsstarke Schutzmaßnahmen, wie die Begrenzung von Systemaufrufen, begrenzen jedoch auch die Funktionalität, die dem Container zur Verfügung steht, und beeinträchtigen sogar die Kompatibilität mit einigen Anwendungen. In der VM-Forschung haben Entwickler immer kleinere und effizientere VMs erstellt, was schließlich zu sogenannten MicroVMs führte. MicroVMs bieten die gleichen Isolationsgarantien wie normale virtuelle Maschinen, sind jedoch in ihren Fähigkeiten in Bezug auf Geräte- oder Betriebssystemunterstützung sehr eingeschränkt, was sie im Vergleich zu normalen VMs leichter und daher besser für serverloses Computing geeignet macht.

Firecracker [1] ist ein Virtual Machine Manager (VMM), der für die Ausführung von Mikro-VMs entwickelt wurde und dabei einen Speicher-Overhead und Startzeiten bietet, die mit denen gängiger Containersysteme vergleichbar sind. Firecracker wird von Amazon Web Services (AWS) aktiv entwickelt und seit 2018 in der Produktion für die serverlosen Rechendienste AWS Lambda [5] und AWS Fargate [4] eingesetzt [1]. Das Designpapier von AWS [1] beschreibt die Funktionen von Firecracker, wie es sich von traditionelleren virtuellen Maschinen unterscheidet und welches Isolationsmodell es bieten soll: Sicherheit für „mehrere Funktionen, die auf derselben Hardware ausgeführt werden, geschützt vor Privilegienausweitung, Informationsoffenlegung, verdeckten Kanälen und anderen Risiken“ [1]. Darüber hinaus bietet AWS Empfehlungen zum Einrichten von Produktionshosts [8] zum Sichern von Teilen der CPU und des Kernels, mit denen eine Firecracker-VM interagiert. In diesem Papier stellen wir die Behauptung in Frage, dass Firecracker Funktionen über Mikro-VMs hinweg vor verdeckten und Nebenkanälen schützt. Wir zeigen, dass Firecracker selbst nicht zu den Gegenmaßnahmen der Mikroarchitektur beiträgt, sondern vollständig auf die Linux-Kernel des Hosts und Gasts sowie auf Firmware-/Mikrocode-Updates der CPU angewiesen ist.

Mikroarchitektur-Angriffe wie die verschiedenen Varianten von Spectre [10, 13, 22, 30, 31, 33, 52] und Microarchitectural Data Sampling (MDS) [14, 37, 46, 50] stellen eine Bedrohung für Multi-Tenant-Systeme dar, da sie oft in der Lage sind, sowohl Software- als auch Architektur-Isolationsgrenzen zu umgehen, einschließlich der von VMs. Spectre und MDS bedrohen Tenants, die CPU-Kernressourcen wie die Branch Prediction Unit (BPU) oder den Line-Fill-Buffer (LFB) gemeinsam nutzen. CSPs, die traditionellere Dienste anbieten, können das Problem gemeinsam genutzter Hardwareressourcen abmildern, indem sie die langlebigen VM-Tenants auf separate CPU-Kerne festlegen, was die Ressourcen effektiv zwischen den Tenants aufteilt und sicherstellt, dass der mikroarchitekturale Zustand immer nur von einem einzigen Tenant gleichzeitig beeinflusst wird.

In serverlosen Umgebungen ist die Gefahr von mikroarchitektonischen Angriffen jedoch größer. Der Grund dafür ist die Kurzlebigkeit der Funktionen, die von den verschiedenen Mandanten ausgeführt werden. Es wird erwartet, dass Serverressourcen in serverlosen Umgebungen überbeansprucht werden, was dazu führt, dass Mandantenfunktionen um Rechenressourcen auf derselben Hardware konkurrieren. Das Deaktivieren von Simultaneous Multi-Threading (SMT), das die gleichzeitige Nutzung von CPU-Ressourcen durch zwei Geschwister-Threads deaktivieren würde, reduziert die Rechenleistung einer CPU um bis zu 30 % [34]. Wenn Kunden bestimmte CPU-Kerne mieten, kann dieser Leistungsverlust akzeptabel sein, oder beide Threads auf einem CPU-Kern können zusammen gemietet werden. Bei serverlosen Diensten bedeutet der Leistungsverlust jedoch direkt 30 % weniger Kunden, die in einer bestimmten Zeit bedient werden können. Aus diesem Grund muss davon ausgegangen werden, dass die meisten serverlosen CSPs SMT in ihren Systemen aktiviert lassen, sofern sie nichts anderes angeben. Die mikroarchitektonische Angriffsfläche ist am größten, wenn SMT aktiviert ist und der bösartige Thread gleichzeitigen Zugriff auf einen gemeinsam genutzten Kern hat. Es gibt aber auch Angriffsvarianten, die genauso gut funktionieren, wenn der Angreifer-Thread die Mikroarchitektur vorbereitet, bevor er den CPU-Kern an den Opfer-Thread abgibt, oder direkt ausgeführt wird, nachdem der Opfer-Thread die Ausführung angehalten hat. Und selbst wenn SMT vom CSP deaktiviert wird (wie es bei AWS Lambda der Fall ist), teilen sich Mandanten die CPUs in dieser zeitgeteilten Weise immer noch mit mehreren anderen.

AWS behauptet, dass Firecracker, wenn es auf einem System mit aktuellen mikroarchitektonischen Abwehrmechanismen läuft, ausreichend Schutz gegen mikroarchitektonische Angriffe bietet [1]. Die Firecracker-Dokumentation enthält auch spezifische Empfehlungen für mikroarchitektonische Sicherheitsmaßnahmen, die aktiviert werden sollten. In dieser Arbeit untersuchen wir die Sicherheitsansprüche und -empfehlungen von Firecracker und decken Versäumnisse in seinen Richtlinien sowie völlig ungemilderte Bedrohungen auf.

Zusammengefasst sind unsere Hauptbeiträge:

• Wir bieten eine umfassende Sicherheitsanalyse der mandantenübergreifenden und mandanten-Hypervisor-Isolierung von serverlosem Computing, wenn es auf Firecracker VM basiert.

• Wir testen Firecrackers Abwehrmöglichkeiten gegen mikroarchitektonische Angriffe anhand von Proof-of-Concepts (PoCs) und nutzen dabei Schutzmechanismen, die durch Mikrocode-Updates und den Linux-Kernel verfügbar sind. Wir zeigen, dass die virtuelle Maschine selbst nur einen vernachlässigbaren Schutz gegen die wichtigsten Klassen mikroarchitektonischer Angriffe bietet.

• Wir identifizieren eine Variante des Medusa-MDS-Angriffs, die von Firecracker-VMs aus ausnutzbar wird, obwohl sie auf dem Host nicht vorhanden ist. Die Kernel-Abwehr, die vor diesem Exploit und den meisten bekannten Medusa-Varianten schützt, wird in den Firecracker-Host-Setup-Empfehlungen von AWS nicht erwähnt. Darüber hinaus zeigen wir, dass das Deaktivieren von SMT keinen ausreichenden Schutz vor der identifizierten Medusa-Variante bietet, was die Notwendigkeit der Kernel-Abwehr unterstreicht.

• Wir identifizieren Spectre-PHT- und Spectre-BTB-Varianten, die trotz empfohlener Gegenmaßnahmen Daten verlieren. Die Spectre-PHT-Varianten bleiben sogar dann ein Problem, wenn SMT deaktiviert ist und Angreifer und Opfer zeitversetzt einen CPU-Kern gemeinsam nutzen.

1.1 Verantwortungsvolle Offenlegung

Wir haben das AWS-Sicherheitsteam über unsere Erkenntnisse informiert und technische Details besprochen. Das AWS-Sicherheitsteam gibt an, dass die AWS-Dienste aufgrund zusätzlicher Sicherheitsmaßnahmen von unseren Erkenntnissen nicht betroffen sind. AWS stimmte zu, dass Firecracker allein keine mikroarchitektonische Sicherheit bietet, sondern nur in Kombination mit Mikrocode-Updates und sicheren Host- und Gastbetriebssystemen, und plant, seine Host-Setup-Empfehlungen für Firecracker-Installationen zu aktualisieren.