V8 Sandbox

• Die V8-Sandbox ist eine leichtgewichtige In-Process-Sandbox für die V8-Engine
• Sie hat nun die Experimentierphase verlassen und wurde in das Vulnerability Reward Program (VRP) von Chrome aufgenommen
  • Es gibt weiterhin Sicherheitsprobleme, die gelöst werden müssen, und Chrome Version 123 kann als „Beta“-Release der Sandbox betrachtet werden

Motivation

• Memory Safety bleibt ein wichtiges Problem: Alle in den letzten drei Jahren entdeckten Chrome-Exploits nahmen ihren Anfang in Memory-Corruption-Schwachstellen in V8
• 60 % dieser Schwachstellen traten in V8 auf, die meisten davon waren jedoch keine „typischen“ Memory-Corruption-Bugs, sondern subtile Logikprobleme
• Die meisten aktuellen Lösungen für Memory Safety lassen sich nicht auf V8 anwenden; auch ein Wechsel zu einer speichersicheren Sprache wie Rust oder Hardware-Funktionen wie Memory Tagging helfen nicht bei den Sicherheitsherausforderungen von V8

V8-(Heap-)Sandbox

• Die Grundidee der Sandbox besteht darin, den Heap-Speicher von V8 zu isolieren, damit sich Memory Corruption nicht auf andere Teile des Prozesses „ausbreitet“
• Sie könnte mit Hardware-Unterstützung implementiert werden, derzeit gibt es jedoch keine geeigneten Hardware-Funktionen, daher wurde sie softwarebasiert umgesetzt
• Die Sandbox ersetzt alle Datentypen, die auf externen Speicher zugreifen können, durch „sandbox-kompatible“ Alternativen
• Nur der V8-Heap innerhalb der Sandbox befindet sich tatsächlich in der Sandbox; das ähnelt dem Sandboxing-Modell von WebAssembly

Performance

• Der wichtigste Vorteil des Sandbox-Ansatzes ist, dass er grundsätzlich geringe Kosten verursacht
• Der Overhead durch die Sandbox entsteht hauptsächlich durch indirekte Verweise über Pointer-Tabellen auf externe Objekte; aktuell liegt der Overhead bei typischen Workloads unter 1 %

Testing

• Testbarkeit einer Sicherheitsgrenze bedeutet in der Praxis die Fähigkeit, manuell und automatisiert zu prüfen, ob die Sicherheitsgarantie tatsächlich eingehalten wird
• Die V8-Sandbox erfüllt alle Anforderungen: ein klares Angreifermodell, eine Möglichkeit zur Nachbildung des Angreifers und eine Methode, automatisch zu erkennen, wenn die Sicherheitsgrenze versagt

Nutzung

• Die V8-Sandbox muss zur Build-Zeit mit dem Build-Flag v8_enable_sandbox aktiviert oder deaktiviert werden.
• Sie ist nur auf 64-Bit-Systemen verfügbar und erfordert derzeit die Reservierung von 1 Terabyte virtuellem Adressraum.
• Die V8-Sandbox ist bereits seit etwa zwei Jahren standardmäßig in 64-Bit-Versionen von Chrome auf Android, ChromeOS, Linux, macOS und Windows aktiviert.

Fazit

• Die V8-Sandbox ist ein neuer Sicherheitsmechanismus, der verhindern soll, dass sich Memory Corruption in V8 auf anderen Speicher des Prozesses auswirkt
• Aktuelle Memory-Safety-Technologien lassen sich größtenteils nicht auf optimierte JavaScript-Engines anwenden, sind aber wirksam beim Schutz der Angriffsfläche der V8-Sandbox
• Die Sandbox ist ein notwendiger Schritt hin zu mehr Memory Safety

Meinung von GN⁺

• Die V8-Sandbox ist eine moderne Gegenmaßnahme gegen Memory-Corruption-Schwachstellen und bietet eine Antwort auf Probleme, die bestehende Memory-Safety-Techniken nicht lösen können
• Angesichts der Komplexität von JavaScript-Engines spielt diese Sandbox eine wichtige Rolle dabei, die Sicherheitsgrenzen weiter zu stärken und die Memory Safety zu verbessern
• Der geringe Performance-Overhead der Sandbox dürfte für Entwickler attraktiv sein und könnte ihre breite Einführung fördern
• Allerdings könnte die Sandbox-Technologie auch völlig neue Sicherheitslücken einführen; das muss durch kontinuierliches Monitoring und Testing kontrolliert werden
• Eine effektive Implementierung der Sandbox spielt eine wichtige Rolle dabei, zu verhindern, dass Angreifer Memory Corruption auf andere Teile des Systems ausweiten, und trägt damit zur Stärkung der Web-Sicherheit bei