Technisches Resümee: KI-Code-Sandboxes: Eine vergleichende Sicherheitsstudie (Teil 1)

Problemstellung

Das Paper adressiert die kritische Herausforderung der Isolation auf Engine-Ebene für KI-Agenten, die unvertrauenswürdigen Code ausführen. Während „Sandboxing“ eine Standard-Verteidigungsklasse in der Sicherheitsliteratur für agentive KI darstellt, mangelt es an einer tiefgehenden, auf Engine-Ebene messbaren Untersuchung darüber, wie verschiedene Produkte den Gast-Code vom Host-Kernel isolieren. Die Dringlichkeit wird durch die Forschung zu „gefährlichen Fähigkeiten“ (dangerous capability research) getrieben, die zeigt, dass KI-Agenten bereits in der Lage sind, mehrstufige Cyber-Angriffe (z. B. Abschluss von 22 der 32 Schritte eines Unternehmensnetzwerk-Angriffs) innerhalb aktueller Rechenbudgets durchzuführen. Die Studie konzentriert sich auf das T0.H2.N2-Bedrohungsmodell: ein Single-Tenant-Betreiber, der unvertrauenswürdigen Code auf seiner eigenen Infrastruktur ausführt, wobei der Betreiber der Infrastruktur vertraut, aber nicht dem Code. Ziel ist es zu messen, wie fünf spezifische KI-Sandbox-Produkte (arrakis, e2b, microsandbox, gvisor, daytona) das Entkommen aus dem Host-Kernel (Host Kernel Escape) und Informationslecks verhindern.

Methodik

Die Studie verwendet ein sechsachsiges, klassenübergreifendes Vergleichs-Framework, das Eigenschaften misst, die durch die zugrunde liegende Engine (MicroVM, Userspace-Kernel oder OCI-Container) bestimmt werden. Die Methodik untersagt explizit eine zusammengesetzte Bewertung (Composite Scoring) oder ein Gesamtranking und liefert stattdessen pro Achse Ordnungsmuster sowie eine Qualifikationsmatrix für das Bedrohungsmodell.

Die sechs Achsen:

1. Host-Angriffsfläche (1.1): Misst den Fußabdruck der Runtime/des Mediators (L2) auf dem Host-Kernel (L1) via strace-Syscall-Zahlen, Seccomp-Filter-Obergrenzen und primitive Erreichbarkeit (14 spezifische Kernel-LPE/Container-Escape-Primitive).
2. Informationsleckage (1.2): Misst, welche host-identifizierenden Daten (CPU, RAM, Kernel-Version, Festplattenseriennummern) über /proc, /sys und /dev an den Gast exponiert werden.
3. Defense-in-Depth-Stapelbarkeit (1.3): Bewertet, ob ein Betreiber zusätzliche Linux-Härtung (Seccomp, AppArmor, User Namespaces etc.) über die Engine-Defaults legen kann.
4. Öffentliche CVE-Historie (1.4): Analysiert die CVEs der letzten 24 Monate für jede Engine und klassifiziert diese nach Auswirkung (Escape, HostLeak, HostDoS).
5. Patch-Kadenz (1.5): Misst die Zeitverzögerung zwischen dem Upstream-Patching und der Verfügbarkeit auf Produktebene, wobei zwischen koordinierten Offenlegungen und „Silent-Fix-First“-Modellen unterschieden wird.
6. Upstream-Fuzzing-Postur (1.6): Bewertet das Vorhandensein von kontinuierlichem öffentlichem Fuzzing, In-Tree-Harnesses und der Zuordnung pro CVE zur Entdeckung durch Fuzzer.

Experimentelles Setup:

• Host: Einzelner Hetzner Bare-Metal-Knoten (Ubuntu 24.04, Kernel 6.8.0).
• Produkte: Fünf Produkte, zugeordnet zu drei Engine-Klassen:
  • MicroVMs: arrakis (Cloud Hypervisor), e2b (Firecracker), microsandbox (libkrun).
  • Userspace-Kernel: gvisor (runsc).
  • OCI-Container: daytona (runc via Docker-CE).
• Verifizierung: Verwendet „Probe“-Tests (Pass/Fail), „Messung“ (Syscall-Zahlen) und „Desk Research“ (CVE/Fuzzing-Analyse).

Zentrale Beiträge und Erkenntnisse

1. Engine-Klassen vs. Produktvarianz

Obwohl sich Engine-Klassen (MicroVM vs. Userspace-Kernel vs. Container) auf architektonischen Achsen (Angriffsfläche, Leckage) klar abgrenzen, tun dies Produkte innerhalb derselben Klasse nicht. Produktbezogene Konfigurationen und Pin-Policies sind oft signifikante Differenzierungsmerkmale, die über die Engine-Klasse selbst hinausgehen.

• Beispiel: arrakis (MicroVM) hat eine „eingefrorene“ Patch-Policy (471+ Tage), während daytona (Container) bei Patches „aktuell“ ist, was die erwartete Sicherheits-Hierarchie basierend auf der Isolationsklasse allein umkehrt.

2. Angriffsfläche und Primitive Erreichbarkeit

• gVisor hat die engste Angriffsfläche (5/14 erreichbare Primitive), da sein Userspace-Kernel Syscalls abfängt.
• Firecracker (e2b) hat die engste Seccomp-Obergrenze (55 Syscalls), weist aber dennoch 2 neue Escape-Klasse-CVEs im Zeitfenster 2026 auf, was beweist, dass eine kleine Angriffsfläche keine Garantie für die Abwesenheit von Bugs in den genutzten Pfaden ist.
• arrakis exponiert eine Live-/dev/kvm-Schnittstelle gegenüber dem Gast, was verschachtelte Virtualisierung ohne Privilegieneskalation ermöglicht und die Kernel-LPE-Angriffsfläche im Vergleich zu anderen MicroVMs erheblich erweitert.

3. Dominanz der Patch-Propagation

Die Studie stellt fest, dass die produktseitige Pin-Policy die dominierende Variable für den Betreiber ist, die bei koordinierten Upstream-Offenlegungen zu ≈0 Tagen Verzögerung aggregiert, im Downstream jedoch von 0 bis 471+ Tagen reicht.

• arrakis und e2b (self-hosted) sind auf älteren Engine-Versionen „eingefroren“ und somit nicht gegen rezente kritische CVEs geschützt (z. B. CVE-2026-45782 für arrakis, CVE-2026-5747 für e2b).
• gVisor folgt einem „Silent-Fix-First“-Modell, bei dem Fixes Monate vor der CVE-Zuweisung ausgeliefert werden, was zu einer negativen Verzögerung führt (Betreiber erhalten Fixes vor der öffentlichen Bekanntgabe).

4. Fuzzing-Postur und „unmessbare“ Risiken

• gVisor ist die einzige Engine mit einem kontinuierlichen öffentlichen Fuzzer (syzkaller) und In-Tree-Harnesses.
• Firecracker und libkrun besitzen keine Upstream-Fuzzing-Infrastruktur.
• Kritische Erkenntnis: Die Kombination aus „MicroVM-Klasse“ (starke Isolation) und „Kontinuierlichem öffentlichem Fuzzer“ (starke Detektion von Restfehlern) ist in diesem Datensatz nicht besetzt.
• libkrun (microsandbox) ist strukturell unmessbar: Es weist 0 veröffentlichte CVEs und keinen Upstream-Fuzzer auf. Das Paper argumenttiert, dass „0 CVEs“ hier ein Fehlen von Signalen ist und nicht ein Beweis für Korrektheit, was zu einem „strukturell unmessbaren“ Risikoprofil führt.

5. Informationsleckage

• MicroVMs leaken im Allgemeinen 0–1 Host-Identifikatoren (konfigurierbare CPU-Strings).
• gVisor leakt 2 Identifikatoren (RAM-Gesamtgröße, BIOS-Produkt) aufgrund von Implementierungslücken in seinem synthetischen /proc.
• daytona leakt 10 Identifikatoren, einschließlich Festplattenseriennummern und vollständiger Kernel-Signaturen, aufgrund der Shared-Kernel-Architektur.

Bedeutung und Ansprüche

Das Paper behauptet, dass kein allgemeines Ranking möglich oder vorgesehen ist. Stattdessen bietet es eine Qualifikationsmatrix für das Bedrohungsmodell, die es Betreibern ermöglicht, vier spezifische Unterfragen zu beantworten:

1. Escape-Resistenz: Kann der Code aus dem Host-Kernel ausbrechen?
2. Reconnaissance-Resistenz: Was kann der Code über den Host erfahren?
3. Härtungskompatibilität: Kann der Betreiber zusätzliche Linux-Härtungsschichten hinzufügen?
4. Patch-Propagation: Erhält der Betreiber Fixes zeitnah?

Zentrale Schlussfolgerungen:

• Trade-offs sind unvermeidlich: Die stärkste Isolationsklasse (MicroVM) korreliert nicht automatisch mit der stärksten Restfehler-Postur (Fuzzing). Betreiber müssen zwischen „stärkster Isolation“ (MicroVMs) und „geringsten Restfehlern“ (gVisor) wählen.
• Produkt-Defaults sind entscheidend: Engine-seitige Stärken (z. B. Cloud Hypervisors per-thread seccomp) können durch produktseitige Defaults (z. B. arrakis' Nested-KVM-Exposition oder e2bs Frozen-Pin) zunichtegemacht werden.
• Die „unmessbare“ Lücke: Das Fehlen von CVEs und Fuzzing bei libkrun schafft ein Risikoprofil, das nicht als „sicher“ oder „unsicher“ interpretiert werden kann, sondern nur als „unmessbar“.
• Methodischer Wandel: Die Studie geht über das einfache „Replay“ von CVEs hinaus und führt eine Meta-Analyse von architektonischen Eigenschaften, Patch-Kadenz und Fuzzing-Investitionen durch, um den aktuellen Stand der KI-Sandbox-Sicherheit zu beschreiben.

Das Paper dient als Baseline für die Messung auf Engine-Ebene und identifiziert spezifische Lücken in der Produktkonfiguration (wie die Nested-KVM-Exposition von arrakis oder das Hardcoding von Privileged: true bei daytona), die sofortige Aufmerksamkeit seitens der Betreiber oder Remediation durch die Upstream-Entwickler erfordern.