Google demonstrē Spectre ievainojamību izmantošanu, pārlūkprogrammā izpildot JavaScript

Google ir publicējis vairākus ekspluatācijas prototipus, kas parāda iespēju izmantot Spectre klases ievainojamības, izpildot JavaScript kodu pārlūkprogrammā, apejot iepriekš pievienotās aizsardzības metodes. Ekspluatācijas var izmantot, lai piekļūtu procesa atmiņai, kas apstrādā tīmekļa saturu pašreizējā cilnē. Lai pārbaudītu eksploīta darbību, tika atvērta vietne leaky.page, un kods, kas apraksta darba loģiku, tika ievietots vietnē GitHub.

Piedāvātais prototips ir paredzēts, lai uzbruktu sistēmām ar Intel Core i7-6500U procesoriem vidē ar Linux un Chrome 88. Lai izmantotu ekspluatāciju citās vidēs, ir nepieciešamas modifikācijas. Ekspluatācijas metode nav raksturīga Intel procesoriem - pēc atbilstošas ​​pielāgošanas tika apstiprināts, ka ekspluatācija darbojas sistēmās ar citu ražotāju CPU, tostarp Apple M1, kura pamatā ir ARM arhitektūra. Pēc nelielām korekcijām izmantošana ir iespējama arī citās operētājsistēmās un citās pārlūkprogrammās, kuru pamatā ir Chromium dzinējs.

Vidē, kuras pamatā ir standarta Chrome 88 un Intel Skylake procesori, bija iespējams nopludināt datus no procesa, kas ir atbildīgs par tīmekļa satura apstrādi pašreizējā Chrome cilnē (renderēšanas process) ar ātrumu 1 kilobaits sekundē. Turklāt ir izstrādāti alternatīvi prototipi, piemēram, ekspluatācija, kas uz stabilitātes samazināšanas rēķina ļauj palielināt noplūdes ātrumu līdz 8kB/s, izmantojot performance.now() taimeri ar precizitāti 5 mikrosekundes (0.005 milisekundes). ). Tika sagatavota arī versija, kas darbojās ar taimera precizitāti līdz vienai milisekundei, ar kuras palīdzību varēja organizēt piekļuvi cita procesa atmiņai ar ātrumu aptuveni 60 baiti sekundē.

Publicētais demonstrācijas kods sastāv no trim daļām. Pirmā daļa kalibrē taimeri, lai novērtētu to darbību izpildes laiku, kas nepieciešamas, lai atjaunotu procesora kešatmiņā palikušos datus, spekulatīvas CPU instrukciju izpildes rezultātā. Otrā daļa nosaka atmiņas izkārtojumu, ko izmanto, piešķirot JavaScript masīvu.

Trešā daļa tieši izmanto Spectre ievainojamību, lai noteiktu pašreizējā procesa atmiņas saturu, radot apstākļus noteiktu darbību spekulatīvai izpildei, kuru rezultātu pēc neveiksmīgas prognozes noteikšanas procesors atmet, bet paliek pēdas izpilde tiek glabāta vispārējā kešatmiņā, un to var atjaunot, izmantojot metodes kešatmiņas satura noteikšanai, izmantojot trešo pušu kanālus, kas analizē piekļuves laika izmaiņas kešatmiņā saglabātajiem un nekešatmajiem datiem.

Piedāvātā ekspluatācijas tehnika ļauj iztikt bez augstas precizitātes taimeriem, kas pieejami, izmantojot performance.now() API, un bez atbalsta SharedArrayBuffer tipam, kas ļauj izveidot masīvus koplietojamā atmiņā. Ekspluatācijā ietilpst sīkrīks Spectre, kas izraisa kontrolētu spekulatīvu koda izpildi, un sānu kanāla noplūdes analizators, kas nosaka spekulatīvās izpildes laikā iegūtos kešatmiņas datus.

Sīkrīks ir ieviests, izmantojot JavaScript masīvu, kurā tiek mēģināts piekļūt apgabalam ārpus bufera robežām, ietekmējot zaru prognozēšanas bloka stāvokli, jo ir iekļauta bufera izmēra pārbaude, ko pievieno kompilators (procesors, skatoties uz priekšu, spekulatīvi veic piekļuvi, bet pēc pārbaudes atceļ stāvokli). Lai analizētu kešatmiņas saturu nepietiekamas taimera precizitātes apstākļos, ir piedāvāta metode, kas maldina procesoros izmantoto Tree-PLRU kešatmiņas izņemšanas stratēģiju un ļauj, palielinot ciklu skaitu, būtiski palielināt laika starpību atgriešanās laikā. vērtība no kešatmiņas un ja kešatmiņā nav vērtības.

Tiek atzīmēts, ka Google publicēja ekspluatācijas prototipu, lai parādītu uzbrukumu iespējamību, izmantojot Spectre klases ievainojamības, un mudinātu tīmekļa izstrādātājus izmantot metodes, kas samazina šādu uzbrukumu riskus. Tajā pašā laikā Google uzskata, ka bez būtiskas piedāvātā prototipa pārstrādāšanas nav iespējams izveidot universālus eksploitus, kas būtu gatavi ne tikai demonstrēšanai, bet arī plašai lietošanai.

Lai samazinātu risku, vietņu īpašnieki tiek aicināti izmantot nesen ieviestās galvenes Cross-Origin Opener Policy (COOP), Cross-Origin Embedder Policy (COEP), Cross-Origin Resource Policy (CORP), Fetch Metadata Request, X-Frame- Opcijas, X satura veida opcijas un SameSite sīkfails. Šie mehānismi tieši neaizsargā pret uzbrukumiem, taču tie ļauj izolēt vietnes datus no noplūdes procesos, kuros var izpildīt uzbrucēja JavaScript kodu (noplūde notiek no pašreizējā procesa atmiņas, kas papildus uzbrucēja kodam , var apstrādāt arī datus no citas vietnes, kas atvērta tajā pašā cilnē). Galvenā ideja ir atdalīt vietnes koda izpildi dažādos procesos no trešās puses koda, kas saņemts no neuzticamiem avotiem, piemēram, iekļauts, izmantojot iframe.



Avots: opennet.ru

Pievieno komentāru