V openSSH 9.1 našli zranitelnost, která umožňuje obejít malloc

Nedávno Qualy's (technologická společnost, která se specializuje na cloudové zabezpečení) oznámil to co jsi našel způsob, jak obejít malloc a dvojitou ochranu pro zahájení křížení pomocí chyby zabezpečení v OpenSSH 9.1.

Zatím bylo stanoveno, že taková zranitelnost je pouze „teoretická“, protože je nepravděpodobné, že vytvoří funkční exploit. Velkou otázkou přitom zůstává možnost vytvoření pracovního exploitu.

Pokud jde o zranitelnost, je zmíněno, že trik, jak obejít ochrany double free a použití po free from malloc je přerozdělit paměť, která byla obsazena od options.kex_algorithms, jakmile bude zdarma.

Z pohledu malloca není učiněn žádný pokus o uvolnění, čtení nebo zápis paměti, která je již volná; z bodu sshd však dochází k útoku aliasingem, protože dva různé ukazatele na dva různé objekty odkazují na stejný kus paměti a zápis do jednoho objektu přepíše druhý objekt.

To otevírá svět možností.

Zahájili jsme vyšetřování knihomola Debian (který používá kód glibc
malloc), ale nakonec jsme přešli na OpenBSD 7.2, protože OpenBSD
malloc (navzdory svému velmi defenzivnímu programování) má dvě vlastnosti, které
aby to bylo obzvláště zajímavé pro tuto konkrétní bezplatnou dvojitou chybu:

Tato chyba zabezpečení je způsobena dvojitým vydáním paměťové oblasti ve fázi předběžné autentizace. Chcete-li vytvořit podmínky pro zranitelnost, stačí změnit banner klienta SSH na "SSH-2.0-FuTTYSH_9.1p1" (nebo jiného starého klienta SSH), abyste dosáhli nastavení příznaků "SSH_BUG_CURVE25519PAD" a "SSH_OLD_DHGEX" Po nastavení těchto příznaků se dvakrát uvolní paměť pro vyrovnávací paměť "options.kex_algorithms".

Výzkumníci společnosti Qualys, v průběhu manipulace se zranitelností, byli schopni získat kontrolu nad registrem procesoru "%rip", A obsahující ukazatel na další příkaz, který se má provést. Vyvinutá technika exploitu umožňuje přenos řízení do libovolného bodu v adresovém prostoru procesu sshd v zastaralém prostředí OpenBSD 7.2, které je standardně dodáváno s OpenSSH 9.1.

Rychlá aktualizace: Byli jsme schopni získat libovolnou kontrolu nad "ripem" přes tuto chybu (tj. v sshd můžeme skákat kamkoli chceme adresní prostor) na neopravené instalaci OpenBSD 7.2 (běžící
OpenSSH 9.1 ve výchozím nastavení). Toto není v žádném případě konec příběhu: toto ePro pouhý krok 1 přeskočte malloca a dvojité stráže.

Další krok, který může nebo nemusí být vůbec proveditelný, jsou:

– krok 2, spusťte libovolný kód navzdory ASLR, NX a ROP
ochrany (to bude pravděpodobně vyžadovat únik informací, buď
stejnou chybou nebo sekundární chybou);

– krok 3, opuštění sandboxu sshd (přes menší chybu, buď v
privilegovaný nadřazený proces nebo ve sníženém počtu útoků na jádro
povrch).

Je třeba poznamenat, že navrhovaný prototyp je implementací pouze první fáze útoku: Chcete-li vytvořit funkční exploit, musíte obejít ochranné mechanismy ASLR, NX a ROP a vymanit se z izolace sandboxu, což je nepravděpodobné.

Řešení problému obcházení ASLR, NX a ROP vyžaduje získání informací o adrese, čehož lze dosáhnout identifikací další zranitelnosti, která vede k úniku informací. Chyba v privilegovaném rodičovském procesu nebo procesu jádra může pomoci vymanit se z izolovaného prostoru.

Uvádí se, že zranitelnost funguje následovně:

• -Za prvé, bezplatné options.kex_algorithms v compat_kex_proposal(), předstírat, že ssh klient je starý "FuTTY" klient.
• -Za druhé, fragment, který byl obsazen options.kex_algorithms, je přerozdělen, se strukturou EVP_AES_KEY, jejíž velikost je 264 bajtů, s výběrem šifry „aes128-ctr“ během fáze výměny klíčů. K tomuto přerozdělení dochází s pravděpodobností ~1/32.
• – Za třetí, uvolnění (znovu) části, která byla obsazena options.kex_algorithms (a nyní je obsazena strukturou EVP_AES_KEY) v kex_assemble_names() (prostřednictvím mm_getpwnamallow()). K tomu dochází tehdy a pouze tehdy, když je první bajt bloku '+', '-' nebo '^' (jinak kex_assemble_names() vrátí chybu a je zavolána fatal_fr()).
• – Za čtvrté, část, která byla obsazena options.kex_algorithms (a nyní je stále označována jako struktura EVP_AES_KEY), je znovu přiřazena s 300 bajtovým řetězcem 'A', "authctxt->user" nebo "authctxt ->style" během fáze ověřování. Toto přerozdělení, které efektivně přepíše celou strukturu EVP_AES_KEY bajty 'A', nastane s pravděpodobností ~2/32.
• – Nakonec skočí na 0x4141414141414141, když sshd volá EVP_Cipher(), protože struktura EVP_AES_KEY obsahuje ukazatel funkce, který byl přepsán našimi bajty 'A' a je volán CRYPTO_ctr128_encrypt_ctr32() (přes EVP_PCipher)

Konečně, pokud máte zájem dozvědět se o tom více, můžete konzultovat podrobnosti Na následujícím odkazu.