Google hat ferskate eksploitaasjeprototypen publisearre dy't de mooglikheid sjen litte om kwetsberens fan Spectre-klasse te eksploitearjen by it útfieren fan JavaScript-koade yn 'e browser, om earder tafoege beskermingmetoaden te omgean. Exploits kinne brûkt wurde om tagong te krijen ta it ûnthâld fan it proses dat webynhâld ferwurket yn 'e aktuele ljepper. Om de wurking fan 'e eksploitaasje te testen, waard de webside leaky.page lansearre, en de koade dy't de logika fan it wurk beskriuwt, waard pleatst op GitHub.
It foarstelde prototype is ûntworpen om systemen oan te fallen mei Intel Core i7-6500U-processors yn in omjouwing mei Linux en Chrome 88. Om de eksploitaasje foar oare omjouwings te brûken, binne modifikaasjes nedich. De eksploitaasjemetoade is net spesifyk foar Intel-processors - nei passende oanpassing waard de eksploitaasje befêstige om te wurkjen oan systemen mei CPU's fan oare fabrikanten, ynklusyf de Apple M1 basearre op ARM-arsjitektuer. Nei lytse oanpassingen is de eksploitaasje ek wurkber yn oare bestjoeringssystemen en yn oare browsers basearre op de Chromium-motor.
Yn in omjouwing basearre op standert Chrome 88- en Intel Skylake-processors wie it mooglik om gegevens te lekken fan it proses ferantwurdlik foar it ferwurkjen fan webynhâld yn 'e hjoeddeistige Chrome-ljepper (rendererproses) mei in snelheid fan 1 kilobyte per sekonde. Dêrnjonken binne alternative prototypen ûntwikkele, bygelyks in eksploitaasje dy't it mooglik makket, op kosten fan it ferminderjen fan stabiliteit, de lekrate te ferheegjen nei 8kB/s by it brûken fan de timer performance.now() mei in krektens fan 5 mikrosekonden (0.005 millisekonden) ). In ferzje waard ek taret dy't wurke mei in timer-krektens fan ien millisekonde, dy't koe wurde brûkt om tagong ta it ûnthâld fan in oar proses te organisearjen mei in snelheid fan sawat 60 bytes per sekonde.
De publisearre demo-koade bestiet út trije dielen. It earste diel kalibreart de timer om de útfieringstiid te skatten fan 'e operaasjes dy't nedich binne om gegevens te herstellen dy't yn' e prosessor-cache bliuwe as gefolch fan spekulative útfiering fan CPU-ynstruksjes. It twadde diel bepaalt de ûnthâldopmaak brûkt by it tawizen fan de JavaScript-array.
It tredde diel eksploitearret direkt de kwetsberens fan Spectre om de ûnthâldynhâld fan it aktuele proses te bepalen as gefolch fan it skeppen fan betingsten foar de spekulative útfiering fan bepaalde operaasjes, wêrfan it resultaat wurdt wegere troch de prosessor nei it fêststellen fan in mislearre foarsizzing, mar spoaren fan 'e útfiering wurde deponearre yn 'e algemiene cache en kin weromset wurde mei metoaden foar it bepalen fan de ynhâld fan' e cache troch tredden kanalen dy't analysearje feroarings yn tagong tiid ta cached en uncached gegevens.
De foarnommen eksploitaasje technyk makket it mooglik om te dwaan sûnder hege-precision timers beskikber fia de performance.now () API, en sûnder stipe foar de SharedArrayBuffer type, dat makket it mooglik om te meitsjen arrays yn dielde ûnthâld. De eksploitaasje omfettet de Spectre-gadget, dy't kontrolearre spekulative útfiering fan koade feroarsaket, en in side-kanaal leakanalysator, dy't cached gegevens ûntdekt dy't krigen binne tidens spekulative útfiering.
It gadget wurdt ymplementearre mei in JavaSkript-array, wêryn in besykjen wurdt makke om tagong te krijen ta in gebiet bûten de buffergrinzen, wat de tastân fan it tûkfoarsizzingsblok beynfloedet fanwegen de oanwêzigens fan in buffergruttekontrôle tafoege troch de kompiler (de prosessor docht spekulatyf de tagong, foarút sjen, mar rôlet werom de steat nei kontrôle). Om de ynhâld fan 'e cache te analysearjen ûnder omstannichheden fan ûnfoldwaande timer-krektens, is in metoade foarsteld dy't de Tree-PLRU-cache-eviction-strategy ferrifelet dy't brûkt wurdt yn processors en makket it mooglik, troch it fergrutsjen fan it oantal syklusen, it ferskil yn' e tiid signifikant te fergrutsjen by it weromkommen in wearde út de cache en as der gjin wearde yn de cache.
It wurdt opmurken dat Google in prototype fan 'e eksploitaasje publisearre om de helberens fan oanfallen sjen te litten mei Spectre-klasse kwetsberens en om webûntwikkelders te stimulearjen om techniken te brûken dy't de risiko's fan sokke oanfallen minimalisearje. Tagelyk is Google fan betinken dat sûnder signifikante werwurking fan it foarstelde prototype it ûnmooglik is om universele eksploaten te meitsjen dy't net allinich foar demonstraasje ree binne, mar ek foar wiidferspraat gebrûk.
Om it risiko te ferminderjen, wurde side-eigners stimulearre om de koartlyn ymplementeare kopteksten Cross-Origin Opener Policy (COOP), Cross-Origin Embedder Policy (COEP), Cross-Origin Resource Policy (CORP), Fetch Metadata Request, X-Frame- Opsjes, X -Content-Type-Opsjes en SameSite Cookie. Dizze meganismen beskermje net direkt tsjin oanfallen, mar se kinne jo sidegegevens isolearje fan lekkage yn prosessen wêryn de JavaScript-koade fan 'e oanfaller kin wurde útfierd (it lek komt foar út it ûnthâld fan it aktuele proses, dat, neist de koade fan 'e oanfaller, , kin ek gegevens ferwurkje fan in oare side iepene yn datselde ljepblêd). It wichtichste idee is om de útfiering fan 'e sidekoade yn ferskate prosessen te skieden fan koade fan tredden ûntfongen fan ûnbetroubere boarnen, bygelyks opnommen fia in iframe.
Boarne: opennet.ru