Google het verskeie ontginningsprototipes gepubliseer wat die moontlikheid toon om Spectre-klas kwesbaarhede te ontgin wanneer JavaScript-kode in die blaaier uitgevoer word, wat voorheen bygevoegde beskermingsmetodes omseil. Uitbuitings kan gebruik word om toegang te verkry tot die geheue van die proses wat webinhoud in die huidige oortjie verwerk. Om die werking van die ontginning te toets, is die webwerf leaky.page van stapel gestuur, en die kode wat die logika van die werk beskryf, is op GitHub geplaas.
Die voorgestelde prototipe is ontwerp om stelsels met Intel Core i7-6500U-verwerkers aan te val in 'n omgewing met Linux en Chrome 88. Om die ontginning vir ander omgewings te gebruik, word modifikasies vereis. Die uitbuitingsmetode is nie spesifiek vir Intel-verwerkers nie - na toepaslike aanpassing is bevestig dat die ontginning op stelsels werk met SVE's van ander vervaardigers, insluitend die Apple M1 gebaseer op ARM-argitektuur. Na geringe aanpassings is die ontginning ook werkbaar in ander bedryfstelsels en in ander blaaiers gebaseer op die Chromium-enjin.
In 'n omgewing gebaseer op standaard Chrome 88- en Intel Skylake-verwerkers, was dit moontlik om data te lek van die proses wat verantwoordelik is vir die verwerking van webinhoud in die huidige Chrome-oortjie (weergawe-proses) teen 'n spoed van 1 kilogreep per sekonde. Daarbenewens is alternatiewe prototipes ontwikkel, byvoorbeeld 'n ontginning wat dit moontlik maak om, ten koste van die vermindering van stabiliteit, die lekkasietempo tot 8kB/s te verhoog wanneer die performance.now() timer met 'n akkuraatheid van 5 mikrosekondes (0.005 millisekondes) gebruik word ). 'n Weergawe is ook voorberei wat met 'n tydhouer-akkuraatheid van een millisekonde gewerk het, wat gebruik kan word om toegang tot die geheue van 'n ander proses te organiseer teen 'n spoed van ongeveer 60 grepe per sekonde.
Die gepubliseerde demo-kode bestaan uit drie dele. Die eerste deel kalibreer die timer om die uitvoeringstyd van die bewerkings te skat wat nodig is om data wat in die verwerkerkas oorbly as gevolg van spekulatiewe uitvoering van SVE-instruksies te herstel. Die tweede deel bepaal die geheue-uitleg wat gebruik word wanneer die JavaScript-skikking toegewys word.
Die derde deel ontgin direk die Spectre-kwesbaarheid om die geheue-inhoud van die huidige proses te bepaal as gevolg van die skep van voorwaardes vir die spekulatiewe uitvoering van sekere operasies, waarvan die resultaat deur die verwerker weggegooi word na die bepaling van 'n onsuksesvolle voorspelling, maar spore van die uitvoering word in die algemene kas gedeponeer en kan herstel word deur metodes te gebruik om die inhoud van die kas te bepaal deur derdeparty-kanale wat veranderinge in toegangstyd tot gekas- en ongekasdata ontleed.
Die voorgestelde uitbuitingstegniek maak dit moontlik om te doen sonder hoë-presisie timers wat beskikbaar is deur die performance.now() API, en sonder ondersteuning vir die SharedArrayBuffer tipe, wat dit moontlik maak om skikkings in gedeelde geheue te skep. Die ontginning sluit die Spectre-toestel in, wat gekontroleerde spekulatiewe uitvoering van kode veroorsaak, en 'n sykanaal-lek-ontleder, wat gekasdata opspoor wat tydens spekulatiewe uitvoering verkry is.
Die gadget word geïmplementeer met behulp van 'n JavaScript-skikking waarin 'n poging aangewend word om toegang tot 'n area buite die grense van die buffer te verkry, wat die toestand van die takvoorspellingsblok beïnvloed as gevolg van die teenwoordigheid van 'n buffergrootte-kontrole wat deur die samesteller bygevoeg is (die verwerker, vooruit kyk, voer die toegang spekulatief uit, maar rol die staat terug nadat dit gekontroleer is). Om die inhoud van die kas te ontleed onder toestande van onvoldoende tydhouer akkuraatheid, is 'n metode voorgestel wat die Tree-PLRU kas uitsettingstrategie wat in verwerkers gebruik word, mislei en dit moontlik maak om, deur die aantal siklusse te verhoog, die verskil in tyd aansienlik te vergroot wanneer teruggekeer word. 'n waarde uit die kas en wanneer daar geen waarde in die kas is nie.
Daar word kennis geneem dat Google 'n prototipe van die uitbuiting gepubliseer het om die haalbaarheid van aanvalle met Spectre-klas kwesbaarhede te wys en om webontwikkelaars aan te moedig om tegnieke te gebruik wat die risiko's van sulke aanvalle verminder. Terselfdertyd glo Google dat dit sonder beduidende herbewerking van die voorgestelde prototipe onmoontlik is om universele uitbuitings te skep wat nie net vir demonstrasie gereed is nie, maar ook vir wydverspreide gebruik.
Om die risiko te verminder, word werfeienaars aangemoedig om die onlangs geïmplementeerde opskrifte Cross-Origin Opener Policy (COOP), Cross-Origin Embedder Policy (COEP), Cross-Origin Resource Policy (CORP), Haal Metadata Request, X-Frame- Opsies, X -Inhoud-tipe-opsies en SameSite-koekie. Hierdie meganismes beskerm nie direk teen aanvalle nie, maar hulle laat jou toe om werfdata van lekkasie te isoleer in prosesse waarin die aanvaller se JavaScript-kode uitgevoer kan word (die lekkasie vind plaas uit die geheue van die huidige proses, wat benewens die aanvaller se kode , kan ook data verwerk vanaf 'n ander webwerf wat in dieselfde oortjie oopgemaak is). Die hoofgedagte is om die uitvoering van die werfkode in verskillende prosesse te skei van derdeparty-kode wat van onbetroubare bronne ontvang word, byvoorbeeld, ingesluit deur 'n iframe.
Bron: opennet.ru