Jie rado openSSH 9.1 pažeidžiamumą, leidžiantį apeiti malloc

Neseniai „Qualys“ (technologijų įmonė, kuri specializuojasi debesų saugos srityje) paviešino ką radai būdas apeiti mallocą ir dviguba apsauga inicijuoti kryžminimą naudojant OpenSSH 9.1 pažeidžiamumą.

Iki šiol buvo nustatyta, kad toks pažeidžiamumas yra tik „teorinis“, nes vargu ar pavyks sukurti veikiančią eksploataciją. Tuo pačiu metu galimybė sukurti darbingą išnaudojimą išlieka didelis klausimas.

Kalbant apie pažeidžiamumą, minima, kad gudrybė apeiti apsaugas du kartus nemokamai ir naudoti po free from malloc yra perskirstyti atmintį, kuri buvo užimta pagal options.kex_algorithms, kai tik ji bus nemokama.

Malloco požiūriu, nesistengiama atlaisvinti, skaityti ar rašyti atminties, kuri jau yra laisva; Tačiau iš sshd taško įvyksta slapyvardžio ataka, nes dvi skirtingos rodyklės į du skirtingus objektus nurodo tą pačią atminties dalį, o įrašymas į vieną objektą perrašo kitą objektą.

Tai atveria galimybių pasaulį.

Pradėjome tyrimą dėl Debian'o knygų kirmino (kuris naudoja glibc kodą
malloc), bet galiausiai perėjome prie OpenBSD 7.2, nes OpenBSD
malloc (nepaisant labai gynybinio programavimo) turi dvi funkcijas, kurios
padaryti jį ypač įdomiu dėl šios konkrečios nemokamos dvigubos klaidos:

Pažeidžiamumas atsirado dėl dvigubo išleidimo atminties srities išankstinio autentifikavimo etape. Norėdami sudaryti sąlygas pažeidžiamumui, tiesiog pakeiskite SSH kliento reklamjuostę į "SSH-2.0-FuTTYSH_9.1p1" (arba kitą seną SSH klientą), kad būtų galima nustatyti "SSH_BUG_CURVE25519PAD" ir "SSH_OLD_DHGEX" vėliavėles Nustačius šias vėliavėles, du kartus atlaisvinama buferio "options.kex_algorithms" atmintis.

Qualys tyrinėtojai, manipuliuojant pažeidžiamumu, sugebėjo valdyti procesoriaus registrą „%rip“, A, kuriame yra žymeklis į kitą vykdytiną sakinį. Sukurta išnaudojimo technika leidžia perkelti valdymą į bet kurį sshd proceso adresų erdvės tašką pasenusioje OpenBSD 7.2 aplinkoje, kuri pagal numatytuosius nustatymus pristatoma kartu su OpenSSH 9.1.

Greitas atnaujinimas: galėjome savavališkai valdyti „plėšimą“ per šią klaidą (t. y. galime peršokti kur norime sshd adreso erdvė) nepataisytoje OpenBSD 7.2 diegime (veikia
OpenSSH 9.1 pagal numatytuosius nustatymus). Tai jokiu būdu nesibaigia: šis elAtlikdami tik 1 veiksmą, praleiskite malloc ir dvigubas apsaugas.

Kitas Žingsnis, kuris gali būti arba visai neįgyvendinamas, yra:

– 2 veiksmas, vykdykite savavališką kodą, nepaisant ASLR, NX ir ROP
apsaugos (tikėtina, kad taip pat reikės informacijos nutekėjimo
dėl tos pačios klaidos arba dėl antrinės klaidos);

– 3 veiksmas, pabėgimas iš sshd smėlio dėžės (per nedidelę klaidą, arba į
privilegijuotajame pirminiame procese arba sumažintoje branduolio atakoje
paviršius).

Pažymima, kad siūlomas prototipas yra tik pirmojo atakos etapo įgyvendinimas: Norint sukurti veikiantį išnaudojimą, reikia apeiti ASLR, NX ir ROP apsaugos mechanizmus ir išeiti iš smėlio dėžės izoliacijos, o tai mažai tikėtina.

Norint išspręsti ASLR, NX ir ROP apėjimo problemą, reikia gauti adreso informaciją, o tai galima padaryti nustatant kitą pažeidžiamumą, dėl kurio gali nutekėti informacija. Privilegijuoto pirminio ar branduolio proceso klaida gali padėti išeiti iš smėlio dėžės.

Minėta, kad pažeidžiamumas veikia taip:

• -Pirma, nemokami options.kex_algorithms faile compat_kex_proposal(), apsimeta, kad ssh klientas yra senas „FuTTY“ klientas.
• - Antra, fragmentas, kurį užėmė options.kex_algorithms, perskirstomas su struktūra EVP_AES_KEY, kurios dydis yra 264 baitai, pasirenkant „aes128-ctr“ šifrą rakto keitimo fazės metu. Šis perskirstymas įvyksta su ~1/32 tikimybe.
• – Trečia, atlaisvinkite (vėl) gabalą, kurį užėmė options.kex_algorithms (ir dabar užima EVP_AES_KEY struktūra) kex_assemble_names() (per mm_getpwnamallow()). Taip atsitinka tada ir tik tada, kai pirmasis gabalo baitas yra „+“, „-“ arba „^“ (kitaip kex_assemble_names() grąžina klaidą ir iškviečiamas fatal_fr().
• – Ketvirta, dalis, kurią užėmė options.kex_algorithms (ir dabar vis dar minima kaip EVP_AES_KEY struktūra), priskiriama iš naujo, naudojant 300 A baitų eilutę, „authctxt->user“ arba „authctxt ->style“. autentifikavimo etapas. Šis perskirstymas, kuris efektyviai perrašo visą EVP_AES_KEY struktūrą „A“ baitais, įvyksta su ~2/32 tikimybe.
• – Galiausiai jis pereina į 0x4141414141414141, kai sshd iškviečia EVP_Cipher(), nes EVP_AES_KEY struktūroje yra funkcijos rodyklė, kuri buvo perrašyta mūsų „A“ baitų ir kurią iškviečia CRYPTO_ctr128_encrypt_ctr32_Cipher() EVPXNUMX_Cipher.

Galiausiai, jei jus domina daugiau apie tai sužinoti, galite susipažinti su išsamia informacija Šioje nuorodoje.