Et nyt projekt håber at øge sikkerheden i V8, en del af Chrome -browseren, som de fleste brugere ikke er klar over, men som hackere i stigende grad ser som et saftigt mål.
JavaScript får internettet til at gå rundt, og Google har måttet lappe flere nul-dages eller tidligere ukendte fejl i Chrome's V8 JavaScript-motor i år. I april indrømmede Google en fejl med høj sværhedsgrad i V8 sporet, da CVE-2021-21224 blev udnyttet i naturen.
Chrome har over to milliarder brugere, så når nul-dages bedrifter rammer Chrome, er det en stor ting. V8, et open source Google -projekt, er en kraftfuld JavaScript -motor til Chrome, der har hjulpet med at fremme web- og webapplikationer. V8 driver også serverens side runtime Node.js.
Nu har Samuel Groß, medlem af Google Project Zero -sikkerhedsforskerteamet, detaljeret et V8 -sandkasseforslag for at hjælpe med at beskytte dets hukommelse mod grimmere fejl i motoren ved hjælp af virtuel maskine og sandboxing -teknologier.
“V8-bugs muliggør typisk konstruktion af usædvanligt kraftfulde bedrifter. Desuden er det usandsynligt, at disse fejl vil blive formindsket af hukommelsessikre sprog eller kommende hardware-assisterede sikkerhedsfunktioner såsom MTE eller CFI,” forklarer Groß og henviser til sikkerhedsteknologier som Microsofts kontrol -flowintegritet (CFI) og Intels kontrol-flowhåndhævelsesteknologier (CET).
“Som følge heraf er V8 især attraktiv for angribere fra den virkelige verden.”
Großs kommentarer tyder på, at endda vedtagelse af et hukommelsessikkert sprog som Rust-som Google har vedtaget for nye Android -kode – ville ikke umiddelbart løse de sikkerhedsproblemer, V8 står over for, som er skrevet i C ++.
Han skitserer også de brede designmål, men signalerer projektets størrelse og understreger, at dette sandkasseprojekt er i sin begyndelse, og at der er nogle store forhindringer at overvinde. Men V8 er et Google-ledet open source-projekt, og i betragtning af at V8 har været kilden til sikkerhedssårbarheder i Chrome, er der en chance for, at et medlem af GPZ's forslag kan komme over hele linjen.
Problemerne påvirker, hvordan browsersoftware interagerer med hardware ud over operativsystemet og har til formål at forhindre fremtidige fejl i V8 i at ødelægge en computers hukommelse uden for V8 -bunken. Dette ville give en angriber mulighed for at udføre ondsindet kode.
En overvejelse for de ekstra sikkerhedsbeskyttelser til V8 er indvirkningen på hardwareydelse. Groß vurderer, at hans forslag ville medføre en overhead på cirka “1% samlet set i den virkelige arbejdsbyrde”.
Groß forklarer problemet med V8, der stammer fra JIT -kompilatorer, der kan bruges, narre en maskine til at udsende maskinkode, der ødelægger hukommelse under runtime.
“Mange V8-sårbarheder, der udnyttes af angribere fra den virkelige verden, er effektivt sårbarheder af 2. orden: grundårsagen er ofte et logisk problem i en af JIT-kompilatorerne, som derefter kan udnyttes til at generere sårbar maskinkode (f.eks. Kode, der mangler en runtime sikkerhedskontrol). Den genererede kode kan derefter igen udnyttes til at forårsage hukommelseskorruption under runtime. “
Han fremhæver også manglerne ved de nyeste sikkerhedsteknologier, herunder hardware-baserede afbødninger, der vil gøre V8 til et attraktivt mål i de kommende år, og derfor er V8 muligvis brug for en sandkasse-tilgang. Disse omfatter:
Angriberen har stor kontrol over hukommelseskorruptionen primitive og kan ofte gøre disse fejl til meget pålidelige og hurtige bedrifter
Hukommelsessikre sprog beskytter ikke mod disse problemer, da de grundlæggende er logiske fejl
På grund af CPU-sidekanaler og styrken af V8-sårbarheder vil kommende hardwaresikkerhedsfunktioner, f.eks. hukommelsesmærkning, sandsynligvis være forbigående det meste af tiden
På trods af at man bagatelliserer sandsynligheden for, at den nye V8 -sandkasse rent faktisk bliver vedtaget, ser forskeren optimistisk ud om sine muligheder for at udføre sit tilsigtede job ved at kræve en angriberkæde sammen to separate sårbarheder for at udføre kode efter eget valg.
“Med denne sandkasse antages det, at angribere er i stand til at ødelægge hukommelse inde i det virtuelle hukommelsesbur vilkårligt og fra flere tråde og vil nu kræve en ekstra sårbarhed for at ødelægge hukommelse uden for den og dermed udføre vilkårlig kode, “skrev han.
Relaterede emner:
Sikkerhed TV Datahåndtering CXO datacentre 