Mikroarchitektonische Sicherheit von AWS Firecracker VMM: Bedrohungsmodelle

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

3. Bedrohungsmodelle

Wir schlagen zwei Bedrohungsmodelle vor, die auf serverlosen Cloud-Systemen auf Firecracker-Basis anwendbar sind:

(1) Das User-to-User-Modell (Abbildung 3): Ein böswilliger Benutzer führt beliebigen Code in einer Sandbox innerhalb einer Firecracker-VM aus und versucht, Daten zu leaken, einzuschleusen oder auf andere Weise Informationen über oder Kontrolle über die Sandbox-Anwendung eines anderen Benutzers zu erlangen. In diesem Modell betrachten wir

(a) die zeitgeteilte gemeinsame Nutzung der Hardware, wobei die Instanzen der beiden Benutzer abwechselnd auf dem CPU-Kern ausgeführt werden, und

(b) physische Co-Location, bei der der Code beider Benutzer gleichzeitig auf Hardware ausgeführt wird, die auf die eine oder andere Weise gemeinsam genutzt wird (beispielsweise zwei Kerne auf derselben CPU oder zwei Threads im selben Kern, wenn SMT aktiviert ist).

(2) Das User-to-Host-Modell (Abbildung 4): Ein böswilliger Benutzer zielt auf eine Komponente des Hostsystems ab: das Firecracker VMM, KVM oder einen anderen Teil des Hostsystemkernels. Für dieses Szenario berücksichtigen wir nur die zeitgeteilte gemeinsame Nutzung von Hardwareressourcen. Dies liegt daran, dass der Host nur dann Code ausführt, wenn die VM des Gastbenutzers beendet wird, z. B. aufgrund eines Seitenfehlers, der vom Hostkernel oder VMM behandelt werden muss.

Bei beiden Modellen gehen wir davon aus, dass ein böswilliger Benutzer die Laufzeitumgebung seiner Anwendung steuern kann. In unseren Modellen verfügen böswillige Benutzer nicht über Gastkernelberechtigungen. Daher gewähren beide Modelle dem Angreifer etwas weniger Berechtigungen als das von [1] angenommene Modell, bei dem der Gastkernel vom VMM ausgewählt und konfiguriert wird, aber angenommen wird, dass er zur Laufzeit kompromittiert wird. Vielmehr entsprechen die Fähigkeiten des Angreifers in unseren Modellen den Fähigkeiten, die Benutzern bei Bereitstellungen von Firecracker in AWS Lambda und Fargate gewährt werden.