GhostRace - uzbrukums spekulatīvajam izpildes mehānismam Intel, AMD, ARM un IBM procesoros

Pētnieku grupa no Vrije Universiteit Amsterdam un IBM ir izstrādājusi jaunu uzbrukumu spekulatīvajam izpildes mehānismam mūsdienu procesoros ar koda nosaukumu GhostRace (CVE-2024-2193). Problēma parādās Intel, AMD, ARM un IBM ražotajos procesoros. Lai demonstrētu uzbrukuma principus, publicēts ekspluatācijas prototips, kas ļauj iegūt datus no Linux kodola atmiņas ar 12 KB/s veiktspēju ar Spectre klases uzbrukumiem raksturīgu uzticamības līmeni. Veicot uzbrukumus virtualizācijas sistēmām, uzbrucējs no viesu sistēmas var noteikt resursdatora vides vai citu viesu sistēmu atmiņas saturu.

Piedāvātā uzbrukuma metode manipulē ar spekulatīvu sacensību apstākļu rašanos, kas var novest pie piekļuves jau atbrīvotajām atmiņas zonām, ja procesors nepareizi prognozē atzarojumus kodā, kas veic nosacītas darbības ar pavedienu sinhronizācijas primitīviem, piemēram, mutex un spinlock. Spekulatīvas piekļuves atmiņai, kas rodas pēc nepareizas prognozes noteikšanas, procesors atmet, bet to izpildes pēdas paliek procesora kešatmiņā un pēc tam var izgūt, izmantojot sānu kanālu analīzi.

Pēc analoģijas ar Spectre v1 ievainojamību izmantošanu, GhostRace uzbrukumam kodolā ir nepieciešamas noteiktas instrukciju secības (sīkrīki), kas noved pie spekulatīvas koda izpildes atkarībā no ārējiem apstākļiem, kurus var ietekmēt uzbrucējs. Optimizācijas nolūkos procesors sāk izpildīt šādus sīkrīkus spekulatīvajā režīmā, bet pēc tam konstatē, ka filiāles prognoze nebija pamatota, un atgriež darbības to sākotnējā stāvoklī.

Sīkrīks tiek veidots, piemēram, no koda sadaļām, kurās stāvoklis tiek pārbaudīts bezgalīgā cilpā un cilpa tiek izieta pēc piekļuves bloķēšanas noņemšanas resursam. Attiecīgi, spekulatīvi izpildot instrukcijas, ir iespējams panākt kļūdainu pārejas aktivizēšanu un ar bloķēšanu aizsargātas instrukciju kopas izpildi, neskatoties uz to, ka resursa bloķēšana paliek neatbrīvota.

GhostRace - uzbrukums spekulatīvajam izpildes mehānismam Intel, AMD, ARM un IBM procesoros

Analizējot Linux 5.15.83 kodola kodu, pētnieki identificēja 1283 sīkrīkus, kas nodrošina spekulatīvu piekļuvi jau atbrīvotajai atmiņai (SCUAF — Speculative Concurrent Use-After-Free). Potenciāli var tikt uzbrukts virtualizācijas sistēmām, jebkuriem OS kodoliem un programmām, kurās tiek pārbaudīti pavedienu sinhronizācijas primitīvi, izmantojot nosacījumu priekšrakstus, un kods tiek izpildīts platformās, kas ļauj spekulatīvi izpildīt atzarošanas darbības (x86, ARM, RISC-V, utt.) .

Uzbrukuma bloķēšanai tiek piedāvāts izmantot sinhronizācijas primitīvu serializāciju, t.i. pievienojot LFENCE procesora instrukciju pēc cmpxchq instrukcijas, kas pārbauda bloķēšanas stāvokli. Piedāvātā aizsardzības metode iekļaušanai Linux kodolā rada veiktspējas sodu aptuveni 5% apmērā LMBench etalonā, jo LFENCE izsaukums atspējo turpmāko instrukciju preventīvo izpildi, pirms ir veiktas visas iepriekšējās darbības.

Linux kodola izstrādātāji un CPU ražošanas uzņēmumi tika informēti par problēmu 2023. gada beigās. AMD publicēja ziņojumu par ievainojamības esamību, kurā ieteica izmantot standarta metodes, lai aizsargātu pret Spectre v1 uzbrukumiem. Intel un ARM vēl nav atbildējuši. Linux kodola izstrādātāji neplāno tuvākajā nākotnē izmantot piedāvāto sinhronizācijas primitīvu serializācijas metodi veiktspējas soda dēļ, taču jau ir ieviesuši nepieciešamos ierobežojumus, lai aizsargātu pret saistīto IPI Storming (Inter-Process Interrupt Storming) izmantošanas paņēmienu ( CVE-2024-26602), ko izmanto ekspluatācijā, lai pārtrauktu procesu īstajā brīdī (pārpludinot CPU kodolu ar pārtraukumiem, kas neļauj pabeigt pārtraukumu apstrādātāju, kas tika aktivizēts procesa darbības laikā), lai nodrošinātu laiku. logs spekulatīvai piekļuvei jau atbrīvotajai atmiņai.

Neskatoties uz to, ka Xen hipervizorā vēl nav identificēti noplūdošie sīkrīki, Xen izstrādātāji ir sagatavojuši izmaiņas, lai ieviestu aizsargāto LOCK_HARDEN bloķēšanas mehānismu, līdzīgi kā iepriekš pievienotā BRANCH_HARDEN aizsardzības metode. Iespējamās negatīvās ietekmes uz veiktspēju, kā arī pierādījumu trūkuma dēļ par uzbrukuma iespējamību Xen, režīms LOCK_HARDEN pēc noklusējuma ir atspējots.

Avots: opennet.ru

Pievieno komentāru