Heap Overflow

Reading time: 7 minutes

Osnovne informacije

Heap overflow je kao stack overflow ali u heap-u. U suštini, to znači da je neki prostor rezervisan u heap-u za skladištenje podataka i skladišteni podaci su bili veći od rezervisanog prostora.

U stack overflow-ima znamo da će neki registri poput pokazivača instrukcija ili stack frame-a biti vraćeni iz stack-a i to bi moglo biti moguće zloupotrebiti. U slučaju heap overflow-a, nema osetljivih informacija koje se po defaultu čuvaju u heap chunk-u koji može biti overflow-ovan. Međutim, to mogu biti osetljive informacije ili pokazivači, tako da kritičnost ove ranjivosti zavisi od koji podaci mogu biti prepisani i kako bi napadač mogao to zloupotrebiti.

Stack Overflow vs Heap Overflow

U stack overflow-ima raspored i podaci koji će biti prisutni u stack-u u trenutku kada se ranjivost može aktivirati su prilično pouzdani. To je zato što je stack linearan, uvek se povećava u kolidirajućoj memoriji, na specifičnim mestima tokom izvršavanja programa stack memorija obično čuva slične vrste podataka i ima neku specifičnu strukturu sa nekim pokazivačima na kraju dela stack-a koji koristi svaka funkcija.

Međutim, u slučaju heap overflow-a, korišćena memorija nije linearna, već su alokacije obično u odvojenim pozicijama memorije (ne jedna pored druge) zbog bins i zona koje razdvajaju alokacije po veličini i zato što se prethodno oslobođena memorija koristi pre nego što se alociraju novi chunk-ovi. Teško je znati objekat koji će kolidirati sa onim koji je ranjiv na heap overflow. Dakle, kada se pronađe heap overflow, potrebno je pronaći pouzdan način da se željeni objekat postavi pored u memoriji onog koji može biti overflow-ovan.

Jedna od tehnika koja se koristi za ovo je Heap Grooming koja se koristi, na primer, u ovom postu. U postu se objašnjava kako kada u iOS kernel-u zona ostane bez memorije za skladištenje chunk-ova, ona se širi za stranicu kernela, a ova stranica se deli na chunk-ove očekivanih veličina koje će se koristiti redom (do iOS verzije 9.2, zatim se ovi chunk-ovi koriste na nasumičan način kako bi se otežala eksploatacija ovih napada).

Stoga, u prethodnom postu gde se dešava heap overflow, kako bi se primorao overflow-ovani objekat da kolidira sa objektom žrtvom, nekoliko kallocs se primorava od strane nekoliko niti kako bi se osiguralo da su svi slobodni chunk-ovi popunjeni i da je stvorena nova stranica.

Da bi se primoralo ovo popunjavanje objektima specifične veličine, out-of-line alokacija povezana sa iOS mach port-om je idealan kandidat. Prilagođavanjem veličine poruke, moguće je tačno odrediti veličinu kalloc alokacije i kada se odgovarajući mach port uništi, odgovarajuća alokacija će odmah biti vraćena kfree.

Zatim, neki od ovih mesta mogu biti oslobođeni. kalloc.4096 slobodna lista oslobađa elemente u redosledu poslednji ulaz-prvi izlaz, što u suštini znači da ako su neka mesta oslobođena i eksploatacija pokušava da alocira nekoliko objekata žrtava dok pokušava da alocira objekat ranjiv na overflow, verovatno je da će ovaj objekat biti praćen objektom žrtvom.

Primer libc

Na ovoj stranici moguće je pronaći osnovnu emulaciju Heap overflow-a koja pokazuje kako prepisivanje prev in use bita sledećeg chunk-a i pozicije prev size omogućava konzolidaciju korišćenog chunk-a (praveći da misli da je neiskorišćen) i zatim ga ponovo alocirati uz mogućnost prepisivanja podataka koji se koriste u drugom pokazivaču.

Još jedan primer iz protostar heap 0 pokazuje vrlo osnovan primer CTF-a gde se heap overflow može zloupotrebiti da pozove funkciju pobednika da dobije zastavicu.

U protostar heap 1 primeru moguće je videti kako zloupotreba buffer overflow-a omogućava prepisivanje u bliskom chunk-u adrese gde će arbitrarni podaci od korisnika biti napisani.

Primer ARM64

Na stranici https://8ksec.io/arm64-reversing-and-exploitation-part-1-arm-instruction-set-simple-heap-overflow/ možete pronaći primer heap overflow-a gde je komanda koja će biti izvršena smeštena u sledećem chunk-u od overflow-ovanog chunk-a. Tako, moguće je modifikovati izvršenu komandu prepisivanjem sa lakom eksploatacijom kao:

python3 -c 'print("/"*0x400+"/bin/ls\x00")' > hax.txt

Drugi primeri

• Auth-or-out. Hack The Box
• Koristimo ranjivost Integer Overflow da dobijemo Heap Overflow.
• Korumpiramo pokazivače na funkciju unutar struct-a prelivene jedinice da postavimo funkciju kao što je system i dobijemo izvršenje koda.

Primer iz stvarnog sveta: CVE-2025-40597 – Nepravilna upotreba __sprintf_chk

U SonicWall SMA100 firmveru 10.2.1.15, modul za reverznu proxy mod_httprp.so alocira 0x80-bajtni heap chunk i zatim konkatenira nekoliko stringova u njega sa __sprintf_chk:

char *buf = calloc(0x80, 1);
/* … */
__sprintf_chk(buf,               /* destination (0x80-byte chunk) */
-1,                /* <-- size argument   !!! */
0,                 /* flags */
"%s%s%s%s",      /* format */
"/", "https://", path, host);

__sprintf_chk je deo _FORTIFY_SOURCE. Kada primi pozitivan size parametar, proverava da li rezultantni string staje unutar odredišnog bafera. Prosljeđivanjem -1 (0xFFFFFFFFFFFFFFFF), programeri su efikasno onemogućili proveru granica, vraćajući ojačani poziv nazad u klasični, nesigurni sprintf.

Zato pružanje predugog Host: zaglavlja omogućava napadaču da prelije 0x80-bajtni deo i prepiše metapodatke sledećeg heap dela (tcache / fast-bin / small-bin u zavisnosti od alokatora). Rušenje se može ponoviti sa:

import requests, warnings
warnings.filterwarnings('ignore')
requests.get(
'https://TARGET/__api__/',
headers={'Host': 'A'*750},
verify=False
)

Praktična eksploatacija bi zahtevala heap grooming da bi se postavio kontrolisani objekat odmah nakon ranjivog dela, ali osnovni uzrok ističe dva važna zaključka:

1. _FORTIFY_SOURCE nije čarobni metak – zloupotreba može poništiti zaštitu.
2. Uvek prosledite ispravnu veličinu bafera porodici _chk (ili, još bolje, koristite snprintf).

References

• watchTowr Labs – Stack Overflows, Heap Overflows and Existential Dread (SonicWall SMA100)