He löysivät openSSH 9.1:stä haavoittuvuuden, joka sallii mallocin ohituksen

äskettäin Qualyn (pilvitietoturvaan erikoistunut teknologiayritys) teki siitä tunnetuksi mitä olet löytänyt tapa ohittaa malloc ja kaksinkertainen suojaus risteytyksen aloittamiseksi käyttämällä OpenSSH 9.1:n haavoittuvuutta.

Toistaiseksi se on päätetty tällainen haavoittuvuus on vain "teoreettista", koska se ei todennäköisesti luo toimivaa hyväksikäyttöä. Samaan aikaan toimivan hyväksikäytön luomisen mahdollisuus on edelleen suuri kysymys.

Haavoittuvuuden osalta mainitaan, että temppu suojausten ohittamiseksi tuplaa ilmaiseksi ja käytä sen jälkeen vapaana mallocista on varatun muistin uudelleenkohdistaminen by options.kex_algorithms heti, kun se on ilmainen.

Mallocin näkökulmasta ei yritetä vapauttaa, lukea tai kirjoittaa muistia, joka on jo vapaana; sshd:n kohdalla tapahtuu kuitenkin aliasing-hyökkäys, koska kaksi erilaista osoitinta kahteen eri kohteeseen viittaavat samaan muistin osaan ja kirjoittaminen yhteen objektiin korvaa toisen objektin.

Tämä avaa mahdollisuuksien maailman.

Aloitimme tutkimisen Debian-kirjamatosta (joka käyttää glibc-koodia
malloc), mutta lopulta vaihdoimme OpenBSD 7.2:een, koska OpenBSD
mallocilla (huolimatta sen erittäin puolustavasta ohjelmoinnista) on kaksi ominaisuutta, jotka
Tee siitä erityisen kiinnostava tämän ilmaisen kaksoisvirheen kannalta:

Haavoittuvuus johtuu kaksoisjulkaisusta muistialueen esitodennusvaiheessa. Haavoittuvuuden edellytysten luomiseksi, vaihda vain SSH-asiakkaan banneri kohtaan "SSH-2.0-FuTTYSH_9.1p1" (tai muuhun vanhaan SSH-asiakasohjelmaan) "SSH_BUG_CURVE25519PAD"- ja "SSH_OLD_DHGEX"-lippujen asettamiseksi. Näiden lippujen asettamisen jälkeen "options.kex_algorithms" -puskurin muisti vapautetaan kahdesti.

Qualys tutkijat, haavoittuvuuden manipuloinnin aikana, pystyivät hallitsemaan prosessorirekisteriä "%rip", A, joka sisältää osoittimen seuraavaan suoritettavaan lauseeseen. Kehitetty hyväksikäyttötekniikka mahdollistaa ohjauksen siirtämisen mihin tahansa kohtaan sshd-prosessin osoiteavaruudessa vanhentuneessa OpenBSD 7.2 -ympäristössä, joka toimitetaan oletuksena OpenSSH 9.1:n mukana.

Pikapäivitys: Pystyimme saamaan "ripauksen" mielivaltaisen hallinnan tämän bugin kautta (eli voimme hypätä minne haluamme sshd:ssä osoiteavaruus) OpenBSD 7.2:n korjaamattomassa asennuksessa (käynnissä
OpenSSH 9.1 oletuksena). Tämä ei suinkaan ole tarinan loppu: tämä eOhita vain vaiheessa 1 malloc ja kaksoissuojat.

El siguiente vaiheet, jotka voivat olla tai eivät ole lainkaan toteutettavissa, ovat:

– vaihe 2, suorita mielivaltainen koodi ASLR:stä, NX:stä ja ROP:sta huolimatta
suojaukset (tämä todennäköisesti edellyttää myös tietovuotoa
saman virheen tai toissijaisen virheen vuoksi);

– vaihe 3, pakeneminen sshd-hiekkalaatikosta (pienen virheen kautta, joko sisään
etuoikeutetussa emoprosessissa tai supistetussa ytimen hyökkäyksessä
pinta).

On huomattava, että ehdotettu prototyyppi on vain hyökkäyksen ensimmäisen vaiheen toteutus: Toimivan hyväksikäytön luomiseksi sinun on ohitettava ASLR-, NX- ja ROP-suojausmekanismit ja päästävä eroon hiekkalaatikon eristyksestä, mikä on epätodennäköistä.

ASLR:n, NX:n ja ROP:n ohitusongelman ratkaiseminen edellyttää osoitetietojen hankkimista, mikä voidaan saavuttaa tunnistamalla toinen tietovuotoon johtava haavoittuvuus. Virhe etuoikeutetussa emo- tai ydinprosessissa voi auttaa murtautumaan ulos hiekkalaatikosta.

Haavoittuvuuden mainitaan toimivan seuraavasti:

• -Ensinnäkin ilmaiset options.kex_algorithms compat_kex_proposal(issa), teeskennellen, että ssh-asiakas on vanha "FuTTY"-asiakas.
• -Toiseksi, option.kex_algorithms:n käyttämä fragmentti allokoidaan uudelleen rakenteella EVP_AES_KEY, jonka koko on 264 tavua, valitsemalla "aes128-ctr" -salauksen avaimen vaihtovaiheen aikana. Tämä uudelleenallokointi tapahtuu todennäköisyydellä ~1/32.
• – Kolmanneksi kex_assemble_names():n (mm_getpwnamallow()) -tiedoston käyttämän osan vapauttaminen (jälleen). Tämä tapahtuu, jos ja vain jos kappaleen ensimmäinen tavu on '+', '-' tai '^' (muuten kex_assemble_names() palauttaa virheen ja fatal_fr() kutsutaan).
• – Neljänneksi, option.kex_algorithms:n varaama osa (ja johon viitataan edelleen EVP_AES_KEY-rakenteella) määritetään uudelleen 300 A-tavun merkkijonolla, "authctxt->user" tai "authctxt ->style" todennusvaihe. Tämä uudelleenallokointi, joka tehokkaasti korvaa koko EVP_AES_KEY-rakenteen 'A'-tavuilla, tapahtuu todennäköisyydellä ~2/32.
• – Lopuksi se hyppää arvoon 0x4141414141414141, kun sshd kutsuu EVP_Cipher(), koska EVP_AES_KEY-rakenne sisältää funktioosoittimen, jonka A-tavumme ylikirjoittivat ja jota CRYPTO_ctr128_encrypt_ctr32_Cipher()_Cipher()_Cipherin kautta kutsuu.

Lopuksi, jos haluat tietää enemmän siitä, voit tutustua yksityiskohtiin Seuraavassa linkissä.