Een nieuw project hoopt de beveiliging van V8 te verbeteren, een onderdeel van de Chrome-browser waarvan de meeste gebruikers zich niet bewust zijn, maar dat hackers steeds meer als een sappig doelwit zien.
JavaScript zorgt ervoor dat het web rondgaat en Google heeft dit jaar meerdere zero-day of voorheen onbekende fouten in Chrome's V8 JavaScript-engine moeten patchen. In april gaf Google toe dat een zeer ernstige bug in V8 werd gevolgd toen CVE-2021-21224 in het wild werd uitgebuit.
Chrome heeft meer dan twee miljard gebruikers, dus wanneer zero-day exploits Chrome treffen, is dat een groot probleem. V8, een open source Google-project, is een krachtige JavaScript-engine voor Chrome die het web en webapplicaties heeft vooruit geholpen. V8 stuurt ook de server-side runtime Node.js aan.
Nu heeft Samuel Groß, een lid van het Google Project Zero-team voor beveiligingsonderzoekers, een V8-sandboxvoorstel uitgewerkt om het geheugen te beschermen tegen vervelendere bugs in de engine met behulp van virtuele machine- en sandboxtechnologieën.
“V8-bugs maken doorgaans de constructie van ongewoon krachtige exploits mogelijk. Bovendien is het onwaarschijnlijk dat deze bugs worden verholpen door geheugenveilige talen of opkomende hardware-ondersteunde beveiligingsfuncties zoals MTE of CFI”, legt Groß uit, verwijzend naar beveiligingstechnologieën zoals Microsoft's Control. -flow integriteit (CFI) en Intel's control-flow handhavingstechnologieën (CET).
“Als gevolg hiervan is V8 vooral aantrekkelijk voor echte aanvallers.”
Groß's opmerkingen suggereren dat zelfs het adopteren van een geheugenveilige taal zoals Rust – die Google heeft geadopteerd voor nieuwe Android-code — zou de beveiligingsproblemen van V8, die is geschreven in C++, niet meteen oplossen.
Hij schetst ook de brede ontwerpdoelstellingen, maar benadrukt de omvang van het project en benadrukt dat dit sandbox-project nog in de kinderschoenen staat en dat er enkele grote hindernissen moeten worden genomen. Maar V8 is een door Google geleid open source-project en aangezien V8 de bron is van beveiligingsproblemen in Chrome, bestaat de kans dat een lid van het voorstel van GPZ de streep haalt.
De problemen zijn van invloed op hoe browsersoftware omgaat met hardware buiten het besturingssysteem en is bedoeld om te voorkomen dat toekomstige fouten in V8 het geheugen van een computer buiten de V8-heap beschadigen. Hierdoor kan een aanvaller kwaadaardige code uitvoeren.
Een overweging voor de aanvullende beveiligingsmaatregelen voor V8 is de impact op de hardwareprestaties. Groß schat dat zijn voorstel zou leiden tot een overhead van ongeveer “1% in het algemeen op real-world workloads”.
Groß legt het probleem uit met V8 dat voortkomt uit JIT-compilers die kunnen worden gebruikt om een machine te misleiden om machinecode uit te zenden die het geheugen tijdens runtime corrumpeert.
“Veel V8-kwetsbaarheden die door echte aanvallers worden uitgebuit, zijn in feite 2e-orde-kwetsbaarheden: de hoofdoorzaak is vaak een logisch probleem in een van de JIT-compilers, die vervolgens kunnen worden misbruikt om kwetsbare machinecode te genereren (bijv. veiligheidscontrole). De gegenereerde code kan vervolgens worden misbruikt om tijdens runtime geheugenbeschadiging te veroorzaken.”
Hij wijst ook op de tekortkomingen van de nieuwste beveiligingstechnologieën, waaronder op hardware gebaseerde mitigaties, die de V8 de komende jaren tot een aantrekkelijk doelwit zullen maken en daarom heeft V8 mogelijk een sandbox-aanpak nodig. Deze omvatten:
De aanvaller heeft een grote mate van controle over de primitieve geheugencorruptie en kan deze bugs vaak omzetten in zeer betrouwbare en snelle exploits
Geheugenveilige talen beschermen niet tegen deze problemen omdat het in wezen logische bugs zijn
Vanwege CPU-zijkanalen en de potentie van V8-kwetsbaarheden, zullen toekomstige hardwarebeveiligingsfuncties, zoals geheugentagging, waarschijnlijk het grootste deel van de tijd kunnen worden omzeild
Ondanks het bagatelliseren van de waarschijnlijkheid dat de nieuwe V8-sandbox daadwerkelijk wordt geadopteerd, lijkt de onderzoeker optimistisch over de vooruitzichten om zijn beoogde werk te doen door van een aanvaller te eisen dat twee afzonderlijke kwetsbaarheden worden samengevoegd om code van hun keuze uit te voeren.
“Met deze sandbox wordt aangenomen dat aanvallers het geheugen binnen de virtuele geheugenkooi willekeurig en vanuit meerdere threads kunnen beschadigen, en dat ze nu een extra kwetsbaarheid nodig hebben om geheugen daarbuiten te beschadigen, en dus om uit te voeren willekeurige code”, schreef hij.
Verwante onderwerpen:
Beveiliging TV-gegevensbeheer CXO-datacenters 