Et nytt prosjekt håper å øke sikkerheten til V8, en del av Chrome -nettleseren som de fleste brukere ikke er klar over, men som hackere i økende grad ser på som et saftig mål.
JavaScript får nettet til å gå rundt, og Google har måttet reparere flere null-dagers eller tidligere ukjente feil i Chrome's V8 JavaScript-motor i år. I april innrømmet Google en feil med høy alvorlighetsgrad i V8 sporet da CVE-2021-21224 ble utnyttet i naturen.
Chrome har over to milliarder brukere, så når null-dagers utnyttelser rammer Chrome, er det en stor sak. V8, et åpen kildekode -Google -prosjekt, er en kraftig JavaScript -motor for Chrome som har hjulpet til med å fremme web- og webapplikasjoner. V8 driver også server-siden runtime Node.js.
Nå har Samuel Groß, medlem av sikkerhetsforskerteamet for Google Project Zero, detaljert et V8 -sandkasseforslag for å beskytte minnet mot styggere feil i motoren ved hjelp av virtuell maskin og sandboxingsteknologi.
“V8-feil muliggjør vanligvis konstruksjon av uvanlig kraftige utnyttelser. Videre vil disse feilene ikke bli redusert av minnesikre språk eller kommende maskinvareassisterte sikkerhetsfunksjoner som MTE eller CFI,” forklarer Groß, med henvisning til sikkerhetsteknologier som Microsofts kontroll -flytintegritet (CFI) og Intels kontrollflythåndhevingsteknologi (CET).
“Som et resultat er V8 spesielt attraktiv for angripere fra den virkelige verden.”
Großs kommentarer tyder på at til og med vedta et minnesikkert språk som Rust-som Google har vedtatt for nye Android -kode – ville ikke umiddelbart løse sikkerhetsproblemene V8 står overfor, som er skrevet i C ++.
Han skisserer også de brede designmålene, men signaliserer prosjektets størrelse og understreker at dette sandkasseprosjektet er i begynnelsen og at det er noen store hindringer å overvinne. Men V8 er et Google-ledet åpen kildekode-prosjekt, og gitt at V8 har vært kilden til sikkerhetsproblemer i Chrome, er det en sjanse for at medlem av GPZs forslag kan komme seg over streken.
Problemene påvirker hvordan nettleserprogramvare samhandler med maskinvare utover operativsystemet og tar sikte på å forhindre at fremtidige feil i V8 ødelegger datamaskinens minne utenfor V8 -haugen. Dette vil tillate en angriper å utføre skadelig kode.
En vurdering av de ekstra sikkerhetsbeskyttelsene for V8 er virkningen på maskinvarens ytelse. Groß anslår at forslaget hans ville forårsake en overhead på omtrent “1% totalt sett på virkelige arbeidsmengder”.
Groß forklarer problemet med V8 som stammer fra JIT -kompilatorer som kan brukes til å lure en maskin til å sende ut maskinkode som ødelegger minne under kjøretid.
“Mange V8-sårbarheter som utnyttes av angripere fra den virkelige verden er effektivt sårbarheter av andre orden: rotårsaken er ofte et logisk problem i en av JIT-kompilatorene, som deretter kan utnyttes til å generere sårbar maskinkode (f.eks. Kode som mangler kjøretid sikkerhetskontroll). Den genererte koden kan deretter igjen utnyttes for å forårsake minnekorrupsjon under kjøretid. “
Han fremhever også manglene ved de nyeste sikkerhetsteknologiene, inkludert maskinvarebaserte begrensninger, som vil gjøre V8 til et attraktivt mål i årene som kommer, og derfor kan V8 trenge en sandkassetilnærming. Disse inkluderer:
Angriperen har stor kontroll over minnekorrupsjonen primitiv og kan ofte gjøre disse feilene til svært pålitelige og raske bedrifter
Minne sikre språk vil ikke beskytte mot disse problemene, ettersom de i utgangspunktet er logiske feil
På grunn av CPU-sidekanaler og styrken til V8-sårbarheter, vil kommende maskinvaresikkerhetsfunksjoner som minnemerking sannsynligvis være forbigående mesteparten av tiden
Til tross for å bagatellisere sannsynligheten for at den nye V8 -sandkassen faktisk blir adoptert, virker forskeren optimistisk om mulighetene for å gjøre den tiltenkte jobben ved å kreve en angriperkjede sammen to separate sårbarheter for å utføre kode etter eget valg.
“Med denne sandkassen antas det at angriperne kan ødelegge minnet inne i det virtuelle minneburret vilkårlig og fra flere tråder, og vil nå kreve et ekstra sårbarhet for å ødelegge minne utenfor det, og dermed utføre vilkårlig kode, “skrev han.
Relaterte emner:
Sikkerhet TV Datahåndtering CXO datasentre 