De hittade en sårbarhet i openSSH 9.1 som gör det möjligt att kringgå malloc

nyligen Qualy's (ett teknikföretag som är specialiserat på molnsäkerhet) gjorde det känt vad har du hittat ett sätt att kringgå malloc och dubbelt skydd för att initiera en crossover med en sårbarhet i OpenSSH 9.1.

Hittills har det bestämts sådan sårbarhet är bara "teoretisk", eftersom det är osannolikt att skapa en fungerande exploit. Samtidigt är möjligheten att skapa en fungerande exploatering fortfarande en stor fråga.

Angående sårbarhet nämns att tricket att kringgå skydden dubbel gratis och använd efter fri från malloc är att omfördela minnet som var upptaget av options.kex_algorithms så snart det är gratis.

Ur mallocs synvinkel görs inga försök att frigöra, läsa eller skriva minne som redan är ledigt; från punkten sshd uppstår dock en aliasattack, eftersom två olika pekare till två olika objekt refererar till samma minnesbit, och en skrivning till ett objekt skriver över det andra objektet.

Detta öppnar upp en värld av möjligheter.

Vi började vår undersökning av Debians bokmask (som använder glibc-koden
malloc), men vi bytte så småningom till OpenBSD 7.2, eftersom OpenBSD
malloc (trots sin mycket defensiva programmering) har två funktioner som
gör det särskilt intressant för denna speciella gratis dubbelbugg:

Sårbarheten beror på en dubbel release av ett minnesområde i förautentiseringsstadiet. För att skapa förutsättningar för sårbarhet, ändra bara bannern för SSH-klienten till "SSH-2.0-FuTTYSH_9.1p1" (eller en annan gammal SSH-klient) för att uppnå inställning av flaggorna "SSH_BUG_CURVE25519PAD" och "SSH_OLD_DHGEX" Efter att ha ställt in dessa flaggor frigörs minnet för bufferten "options.kex_algorithms" två gånger .

Qualys forskare, i samband med sårbarhetsmanipulation, kunde få kontroll över processorregistret "%rip", A som innehåller en pekare till nästa sats som ska köras. Exploateringstekniken som utvecklats tillåter att kontroll överförs till vilken punkt som helst i adressutrymmet för sshd-processen i en föråldrad OpenBSD 7.2-miljö, som levereras som standard med OpenSSH 9.1.

Snabb uppdatering: Vi kunde få godtycklig kontroll över "rippen" via denna bugg (dvs vi kan hoppa vart vi vill i sshd's adressutrymme) på en oparpad installation av OpenBSD 7.2 (körs
OpenSSH 9.1 som standard). Detta är inte på något sätt slutet på historien: detta eFör bara steg 1, hoppa över malloc och dubbla skydd.

följande steg som kanske inte alls är genomförbara är:

– steg 2, exekvera godtycklig kod trots ASLR, NX och ROP
skydd (detta kommer sannolikt att kräva en informationsläcka heller
av samma fel eller av ett sekundärt fel);

– steg 3, fly sshd-sandlådan (via en mindre bugg, antingen in
den privilegierade överordnade processen eller i den reducerade kärnattacken
yta).

Det noteras att den föreslagna prototypen är implementeringen av endast det första steget av attacken: För att skapa ett fungerande utnyttjande måste du kringgå ASLR-, NX- och ROP-skyddsmekanismerna och bryta dig ur sandlådeisoleringen, vilket är osannolikt.

För att lösa problemet med att kringgå ASLR, NX och ROP krävs adressinformation, vilket kan åstadkommas genom att identifiera en annan sårbarhet som leder till informationsläckage. En bugg i en privilegierad förälder- eller kärnprocess kan hjälpa till att ta sig ut ur sandlådan.

Sårbarheten nämns att fungera enligt följande:

• -För det första, gratis options.kex_algorithms i compat_kex_proposal(), låtsas att ssh-klienten är en gammal "FuTTY"-klient.
• -För det andra omfördelas fragmentet som ockuperades av options.kex_algorithms, med en EVP_AES_KEY-struktur vars storlek är 264 byte, genom att välja "aes128-ctr"-chifferet under nyckelutbytesfasen. Denna omfördelning sker med en sannolikhet på ~1/32.
• – För det tredje, frigör (igen) den bit som var upptagen av options.kex_algorithms (och nu är upptagen av EVP_AES_KEY-strukturen) i kex_assemble_names() (via mm_getpwnamallow()). Detta händer om och endast om den första byten av biten är '+', '-' eller '^' (annars returnerar kex_assemble_names() ett fel och fatal_fr() anropas).
• – För det fjärde tilldelas den bit som ockuperades av options.kex_algorithms (och fortfarande hänvisas till som en EVP_AES_KEY-struktur nu) med en 300 'A'-bytesträng, "authctxt->user" eller "authctxt ->style" under autentiseringsfas. Denna omallokering, som effektivt skriver över hela EVP_AES_KEY-strukturen med 'A'-bytes, sker med en sannolikhet på ~2/32.
• – Slutligen hoppar den till 0x4141414141414141 när sshd anropar EVP_Cipher(), eftersom EVP_AES_KEY-strukturen innehåller en funktionspekare som skrevs över av våra "A"-bytes och anropas av CRYPTO_ctr128_encrypt_ctr32)(Ciphervia EVP)(C)

Slutligen, om du är intresserad av att veta mer om det kan du läsa detaljerna I följande länk.