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

Společnost Qualys (technologická společnost specializující se na cloudovou bezpečnost) nedávno oznámila , že našla způsob, jak obejít ochranu malloc a no-double a zahájit přenos kódu pomocí zranitelnosti v OpenSSH 9.1.

Tato zranitelnost byla zatím považována pouze za „teoretickou“, protože je nepravděpodobné, že by vytvořila funkční exploit. Možnost vytvoření funkčního exploitu však zůstává velkou otázkou.

Pokud jde o tuto zranitelnost, uvádí se, že trik, jak obejít ochrany double free a use-after-free funkce malloc, spočívá v opětovném přiřazení paměti, která byla obsazena funkcí options.kex_algorithms, jakmile je uvolněná.

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 zranitelnost pramení z dvojitého uvolnění oblasti paměti během fáze předběžného ověřování. Chcete-li vytvořit podmínky pro tuto zranitelnost, jednoduše změňte banner SSH klienta na „SSH-2.0-FuTTYSH_9.1p1“ (nebo jiného staršího SSH klienta), abyste povolili konfiguraci příznaků „SSH_BUG_CURVE25519PAD“ a „SSH_OLD_DHGEX“. Po nastavení těchto příznaků se paměť pro vyrovnávací paměť „options.kex_algorithms“ uvolní dvakrát.

Během zneužití zranitelnosti se výzkumníkům ze společnosti Qualys podařilo získat kontrolu nad registrem procesoru „% rip“, který obsahuje ukazatel na další instrukci, která má být provedena. Technika zneužití, kterou vyvinuli, jim umožňuje přenést řízení na libovolný bod v adresním prostoru procesu sshd v neaktualizované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ší kroky, které mohou být proveditelné, ale také nemusí být, 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 zjištěno, že navrhovaný prototyp je implementací pouze první fáze útoku: pro vytvoření funkčního exploitu je nutné obejít ochranné mechanismy ASLR, NX a ROP a opustit izolaci 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)

A konečně, pokud máte zájem dozvědět se více, podrobnosti naleznete na následujícím odkazu.