Guglo publikigis plurajn ekspluatprototipojn montrantajn la eblecon ekspluati vundeblecojn de la klaso Spectre dum ekzekuto de JavaScript-kodo en retumilo, preterirante antaŭe aldonitajn protektajn metodojn. Eksplotoj povas esti uzataj por akiri aliron al la memoro de procezo, kiu prilaboras retenhavon en la nuna langeto. Por testi la funkciadon de la ekspluato, la retejo leaky.page estis lanĉita, kaj la kodo priskribanta la logikon de la laboro estis afiŝita sur GitHub.
La proponita prototipo estas desegnita por ataki sistemojn kun procesoroj Intel Core i7-6500U en medio Linukso kaj Chrome 88. Ŝanĝoj estas postulataj por apliki la ekspluatadon al aliaj medioj. La metodo de ekspluatado ne estas specifa por Intel-procesoroj - post taŭga adapto, la ekspluatado estis konfirmita funkcii sur sistemoj kun CPUoj de aliaj produktantoj, inkluzive de la Apple M1 bazita sur la ARM-arkitekturo. Post etaj ĝustigoj, la ekspluato ankaŭ funkcias sur aliaj operaciumoj kaj aliaj retumiloj bazitaj sur la Chromium-motoro.
En medio bazita sur normaj Chrome 88 kaj Intel Skylake-procesoroj, datumoj estis likitaj de la procezo respondeca pri prilaborado de retejo-enhavo en la nuna Chrome-langeto (bildprocezo), kun rapideco de 1 kilobajto je sekundo. Aldone, alternativaj prototipoj estis evoluigitaj, ekzemple, ekspluato kiu permesas, je la kosto de reduktado de stabileco, pliigi la likrapidecon al 8kB/s dum uzado de la performance.now() tempigilo kun precizeco de 5 mikrosekundoj (0.005 milisekundoj) . Variaĵo ankaŭ estis preparita, laborante kun tempigilo precizeco de unu milisekundo, kiu povus esti uzita por organizi aliron al la memoro de alia procezo kun rapideco de proksimume 60 bajtoj je sekundo.
La publikigita demokodo konsistas el tri partoj. La unua parto kalibras la tempigilon por taksi la ekzekuttempon de la operacioj postulataj por reestigi datenojn forlasitajn en la procesorkaŝmemoro kiel rezulto de konjekta ekzekuto de CPU-instrukciaĵo. La dua parto determinas la memoraranĝon uzatan kiam oni asignas la JavaScript-tabelon.
La tria parto rekte ekspluatas la vundeblecon Spectre por determini la enhavon de la memoro de la nuna procezo kiel rezulto de kreado de kondiĉoj por la konjekta ekzekuto de certaj operacioj, kies rezulto estas forĵetita de la procesoro post determini malsukcesan antaŭdiron, sed ekzekuto. spuroj estas deponitaj en la ĝenerala kaŝmemoro kaj povas esti restarigitaj uzante metodojn por determini la enhavon de la kaŝmemoro per triapartaj kanaloj kiuj analizas ŝanĝojn en alirtempo al kaŝmemoritaj kaj ne-kaŝmemorigitaj datenoj.
La proponita ekspluata tekniko forigas la altprecizajn tempigilojn disponeblajn per la performance.now() API, kaj sen subteno por la tipo SharedArrayBuffer, kiu permesas krei tabelojn en komuna memoro. La ekspluato inkluzivas la Spectre-aparaton, kiu kaŭzas kontrolitan konjektan kodon-ekzekuton, kaj flankkanalan likan analizilon, kiu determinas la datumojn akiritajn dum la konjekta ekzekuto, kiu eniris la kaŝmemoron.
La ileto estas efektivigita uzante JavaScript-tabelon, en kiu provo estas farita por aliri areon ekster la limoj de la bufro, influante la staton de la branĉa prognozbloko pro la bufrograndeckontrolo aldonita fare de la kompililo (la procesoro, rigardante antaŭen. , konjekte elfaras la aliron, sed retroiras la staton post la kontrolo). Por analizi la enhavon de la kaŝmemoro sub kondiĉoj de nesufiĉa tempigilo-precizeco, metodo estas proponita kiu trompas la Tree-PLRU-kaŝmemorforigstrategion uzitan en procesoroj kaj permesas, pliigante la nombron da cikloj, signife pliigi la diferencon en tempo kiam li resendas. valoro el la kaŝmemoro kaj kiam ne estas valoro en la kaŝmemoro.
Oni rimarkas, ke Google publikigis prototipan ekspluatadon por montri la realismon de atakoj uzantaj vundeblecojn de la Spectre-klaso kaj instigi retajn programistojn uzi teknikojn, kiuj minimumigas la riskojn de tiaj atakoj. Samtempe, Google opinias, ke sen grava revizio de la proponita prototipo, estas neeble krei universalajn ekspluatojn, kiuj estas pretaj ne nur por pruvo, sed ankaŭ por vasta uzo.
Por redukti riskon, retejposedantoj estas instigitaj uzi la lastatempe efektivigitan Trans-Originan Malfermpolitikon (COOP), Cross-Origin Embedder Policy (COEP), Cross-Origin Resource Policy (CORP), Fetch Metadata Request, X-Frame-Options, X -Enhavo-Tipo-Opcioj kaj SameSite Kuketoj. Ĉi tiuj mekanismoj ne rekte protektas kontraŭ atakoj, sed ebligas izoli retejajn datumojn de elfluado en procezojn en kiuj la Ĝavoskripto-kodo de la atakanto povas esti efektivigita (la liko okazas el la memoro de la nuna procezo, en kiu, krom la kodo de la atakanto, datumoj de alia retejo malfermita en tiu sama langeto). La ĉefa ideo estas apartigi en malsamaj procezoj la ekzekuton de la retejo-kodo de triaparta kodo akirita de nefidindaj fontoj, ekzemple, inkluzivita per iframe.
fonto: opennet.ru