Malloc Demistyfied Part II by wintermuth anikolic@phearless.org anikolic.phearless.org 01. - Intro 02. - diff glibc-2.3.2 glibc-2.3.5 03. - Double free protections 04. - Unlink technique kaput 05. - Malloc Maleficarum 05.1 - House Of Prime 05.2 - House Of Mind 01. - Intro Ok, proslo je dosta vremena od prvog dela, obecao sam drugi i evo sad sam na pragu da ispunim obecanje. Doduse nisam siguran da se iko nadao nastavku prvog teksta u petom broju zinea, osim Shatterhanda naravno , koji se mnogo nervirao oko kolicine tekstova koje smo imali pred njegovo objavljivanje. Morao sam da ga razocaram tada , ali sam zato napisao neke druge stvari, koje su nadam se bile interesantne vama barem koliko i meni( to se odnosi na one koji su ih citali:)). E sad, secate se kako sam u prvom delu napisao kako unlink() tehnika nebi trebalo da radi kod mene? Ipak je radila zato sto sam tada imao stariju verziju glibc-a koja je imala stariju implementaciju alokatora memorije bez nekih zastita koje bi unlink tehniku iskoriscavanja heap overflowa onemogucila. Sad sam presao na novi slackware koji iam noviji glibc i ima te zastite. Prosto mozemo ih demonstrirati ovako: ---------------code snip------------- main() { char *p; p = (char *) malloc(4); free(p); free(p); } ---------------/code snip------------- bash-3.00$ gcc dfree.c -o dfree bash-3.00$ ./dfree *** glibc detected *** double free or corruption (fasttop): 0x08049680 *** Aborted bash-3.00$ Ovo je prost double free slucaj. Na starom glibcu bi se program srusio, ovde double free biva detektovan program se gasi. Da probamo i stari exploit na starom ranjivom programu. Sve je isto samo novi glibc sa dodatnim zastitama. Opet se dogadja isto. Corumpiranje biva detektovano. Ja sam nedavno poceo da se igram na www.smashthestack.org. To je zajednica koja ima par wargameova. Igrao sam blowfish wargame da bih presao na tux koji je jako interesantan. Blowfish je pocetnicki, ali je takodje jako interesantna. Poslednji nivo blowfisha zahteva poznavanje heap exploitation tehnika. Naravno ja sam uzeo i skinuo source problematincog nivoa, to je level11. Sve izgleda vrlo prosto, sa samo par otezavajucih stvari koje nama u sustini nisu bitne. Kako sam exploit pisao lokalno morao sam da zaobidjem gore demonstrirane zastite koje moj novi glibc ima. Mozete zamisliti moju frustraciju kada sam uploadovao moj exploit na blowfish server i pokrenuo ga. Zamislite , nije radio. Blowfish je pod nekim debian linuxom i ima stariji glibc, znaci nisam uopste morao da zaobilazim zastite jer ih nije ni bilo. Nista , bootovao sam stari knoppix cd i u njemu napisao exploit koji je radio. Sve ovo pricam samo da bih se hvalio kako sam presao wargame i da bih objasnio zasto sam poceo da pisem drugi deo teksta. Znaci, prvo cu se potruditi da objasnim u cemu se sastoje ti dodaci,zastite i sl. A onda i objasniti kako mogu da se zaobidju. 02. - diff glibc-2.3.2 glibc-2.3.5 Ajde da pogledamo sourceve. Glibc na starom slacku mi je bio 2.3.2 a na novom je 2.3.5. Nama je najbitnija u stvari sama unlink() funkicja , koja je ustvari makro, ajde da vidimo ima li razlike. Za divno cudo ima. Stari (2.3.2) glibc: malloc.c/1950 : /* Take a chunk off a bin list */ #define unlink(P, BK, FD) { \ FD = P->fd; \ BK = P->bk; \ FD->bk = BK; \ BK->fd = FD; \ } Noviji (2.3.5) glibc: malloc.c/1983 : #define unlink(P, BK, FD) { \ FD = P->fd; \ BK = P->bk; \ if (__builtin_expect (FD->bk != P || BK->fd != P, 0)) \ malloc_printerr (check_action, "corrupted double-linked list", P); \ else { \ FD->bk = BK; \ BK->fd = FD; \ } \ } Razlika je upravo neka vrsta provere. Treba ispitati sta ona u stvari radi. Da bi ste me pratili preporucio bih da i sami gledate sourceve jer je tako najbolje.Ovaj __builtin_expect() je ustvari makro koji je definisan ovako : #define __builtin_expect(expr, val) (expr) Ovo mi nije bas najjasnije. ovo znaci da __builtin_exepect ustvari predstavlja vrednost izraza expr i u zavisnosti da li je on tacan ili nije nastavlja dalje. Ovaj if bi bio potpuno ist i bez ove __builtin_exepect funkcije. Znaci if(FD->bk != P || BK->fd != P) bi dalo isti rezultat. To je verovatno zbog nekakve optimizacije u kompajleru ili nesto ludacko. Jednostavno njihov nacin da rade assert. No to sto to nema smisla nije bitno. U celom malloc.c ima na desetine slicnih provera od kojih pojedine vracaju odredjeni rezultat na stderr. 03. - Double free protections Setite se sta smo dobili kod onog double free bug-a: *** glibc detected *** double free or corruption (fasttop): 0x08049680 *** Ako bacimo pogled na malloc.c videcemo i kod koji je odgovoran za ovo: ---------------code snip------------- void _int_free(mstate av, Void_t* mem) [1] { ... mfastbinptr* fb; /* associated fastbin */ [2] ... fb = &(av->fastbins[fastbin_index(size)]); [3] /* Another simple check: make sure the top of the bin is not the record we are going to add (i.e., double free). */ if (__builtin_expect (*fb == p, 0)) [4] { errstr = "double free or corruption (fasttop)"; [5] goto errout; } ... ---------------/code snip------------- Procesiranje tog chunka po drugi put je prekinuto u ovom delu koda jer je veoma mali deo memorije alocitran prvobitnim pozivom, a za te veoma male delove ili fasbinove je zaduzen fastbin kod. Tacnije svaki zahtev za alociranjem koji je manji od av->max_fast je fastbin.Ako bi smo u samom programu promenili parametar malloc() pozivu u nesto vece ( 1000 recimo) drugi deo koda bi bio izvrsen ali bi doslo do iste stvari uglavnom : bash-3.00$ ./dfree *** glibc detected *** double free or corruption (top): 0x08049680 *** Aborted bash-3.00$ Za ovo je zaduzen sledeci deo koda: ---------------code snip------------- /* Lightweight tests: check whether the block is already the top block. */ if (__builtin_expect (p == av->top, 0)) { errstr = "double free or corruption (top)"; goto errout; } ---------------/code snip------------- Bazicno rade istu stvar. U fasbin kodu se proverava da li je p odnosno chunk koji treba da se oslobodi vec postavljen kao *fb [4](radi lakseg pracenja obelezio sam relevantne linije probjevima u gornjem isecku iz source-a) . Ako pogledate gore u izvod iz _int_free() vidimo sta je *fb [1]. A vrednost za *fb koja je nama problem dobijamo u [3]. av je pointer ka areni koja odgovara tom chunku. Tako da je tu jedina stvar koju mozemo da kontrolisemo da bi zaobisli ovaj test size vrednost. Velicina nekog chunka se dobija uz pomoc chunksize() makroa koji u stvari izlgeda ovako: /* Get size, ignoring use bits */ #define chunksize(p) ((p)->size & ~(SIZE_BITS)) Kao sto sam kaze , jednostavno maskira nepotrebne bitove iz size polja nekog chunka. Sto znaci da kad bi smo nekako mogli da kontrolisemo size polje chunka pre drugog free poziva trebalo bi da prodjemo ovaj test. Dodajmo nesto u oanj dfree.c programcic. Sada on izgleda ovako: --------dfree.c------------ main() { char *p,*b; p = (char *) malloc(4); free(p); b = p - 4; *b = 32; free(p); } --------/dfree.c------------ Jednostavno samo sam promenio size vrednost koju procesira drugi free poziv i test je zaobidjen. Ali sada se desava nesto drugo : bash-3.00$ ./dfree *** glibc detected *** free(): invalid next size (fast): 0x08049690 *** Aborted bash-3.00$ E sad, posto smo promenili size ovog chunka , sledeci test trazi size sledeceg chunka malo dalje sto naravno nije tacno i zato biva prekinuto izvrsenje. Ali ja mogu da stavim velicinu tog chunka da bude manja nego sam taj chunk i da pokazuje na neko mesto unutar nejga , gde mogu da stavim neki broj koji bi free procesirao kao next_size i test bi opet prosao ili ako uslovi u ranjivoj aplikaciji dozvoljavaju, mogu da jadnostavno na udaljenost na kojij bi ovaj test trazio velicinu sledeceg upisem vrednost koja bi ga zadovoljila i time opet prosao test. Prost primer: --------dfree.c------------ main() { char *p,*b; p = (char *) malloc(4); free(p); b = p - 4; *b = 4; free(p); } --------/dfree.c------------ Kada pokrenem: bash-3.00$ ./dfree Segmentation fault Segmentation fault zato sto se nisam potrudio da stavim nesto pametno na mesto gde se vrsi provera. Ili drugi glupi primer: --------dfree.c------------ main() { char *p,*b; p = (char *) malloc(4); free(p); b = p - 4; *b = 32; b = p + 32 -4; *b = 32; free(p); } -------------/dfree.c--------------- Pokrenuto : bash-3.00$ ./dfree bash-3.00$ Sve je naizgled u redu , osim sto taj proces ima korumpiran heap ali mu nije ni bitno jer se odmah zavrsava i ta korumpirajnnost nu nikako ne skodi. Nisam zamislio ovaj tekst kao objasnjenej doble free eksploatacije ali mi je ovo izlgedalo kao dobar uvod u zloglasne zastite u glibcu koje sam nadam se do sada bar pojasnio. Sanse su da ce se u nekoj ranjivaoj aplikaciji koju budete pokusavali da exploitujete javiti ovakvi uslovi koji ce vam omoguciti zaobilazenje ovih testova. U sustini sve sto vam treba jeste mogucnost da kontrolisete pojedine vrednosti i sadrzaj korumpitranog chunka. 04. - Unlink technique kaput Sad da se vratimo na onaj ranjiv program i exploit iz prvog teksta, da vidimo sta on sad kaze: bash-3.00$ ./vuln asd 0x8049720 bash-3.00$ objdump -R ./vuln | grep free 080496b8 R_386_JUMP_SLOT free bash-3.00$ gcc expl.c -o expl bash-3.00$ ./expl 0x8049720 *** glibc detected *** double free or corruption (!prev): 0x08049720 *** Aborted bash-3.00$ Bacimo pogleda na malloc.c da vidimo gde se ovo u stvari desava: /* Or whether the block is actually not marked used. */ if (__builtin_expect (!prev_inuse(nextchunk), 0)) { errstr = "double free or corruption (!prev)"; goto errout; } Ovo jednostavno proverava da li je trenutni chunk u upotrebi. Ako se secate, za unlink tehniku bilo je krucialno skloniti prev_inuse sledeceg chunka da bi ona uspela. Ovde vidimo da ce ako prev_inuse() na sledecem chunku vrati 0, sto je neophodno da bi unlink tehnika uspela, dalje procesiranje chunka biti prekinuto. Ovime je ova tehnika uspesno pobedjena i nema nacina da se zaobidje ovaj test a da tehnika idalje radi. Vodjen idejom da nadje nove mogucnosti napada phantasmal phantasmagoria, virtual adept, je razvio svoje tehnike koje cu ja, nadam se bar, da pojasnim. 05. - Malloc Maleficarum Kako i sam phantasmal kaze, prva tehnika koju je nasao je i najgora i najmanje moguca, recima nekoga sa irc.pulltheplug.org, izgleda da bi radila samo u vreme punog meseca. To je House Of Prime tehnika. Dublje shvatajuci samu tehniku dosao sam do najveceg uslova koji ona trazi za uspesno izvrsenje. To je uslov da arena_key mora biti na visoj adresi od arena strukture. Posto one dolaze iz razlicitih fajlova obe mogucnosti su moguce( da budu ili ne budu na odgovarajucim adresama) Posto je potrebno znati adresu arena_key potrebno je imati glibc kompajliran sa simbolima da bi gdb mogao da pronadje ono sto mu treba, ja na mojjoj default slackware instalaciji to nemam pa sam zato rekompajlirao malloc strukture sa ukljucenim define-om da sve malloc.c funkcije imaju dl prefiks, kako mi novokompajlirani memory alokator nebi praivo problema. Problem je nastao upravo tu, jer su mi potrebne adrese bie upravo suprotno od on ga sto House Of Prime zahteva. Tako da za nju za sada necete dobiti PoC vecc samo indepth objasnjenje njene ideje. Zaista me mrzi da se petljam da bi naterao novokompajliranu stvar da ima odgovarajuce adrese. Imam posla preko glave, a i leto nije bas moje omiljeno doba za sedenje za kompjuterom. PoC za ovu tehniku ce te nadam se moci da vidite za neko vreme, a ako ga sami napisete pre mene, zamolio bih vas da mi ga posaljete. 05.1 - The House Of Prime Osnovne uslovi za House Of Prime jesu da mozete da uradite free() na dva razlicita chunka cija size polja mozete da kontrolisete, a zatim jos jedan malloc() poziv. Pocnimo od prvog free() poziva. Najmanja velicina memorije koju vam malloc() moze alocirati jeste 16 bajta. 8 bajta za informacije i 8 bajta za podatke. Znaci malloc(0) ustvari alocira 16 bajta. Prva stvar koja treba da se uradi u House Of Prime jeste da se prepise av->max_fast varijabla. Ako pogledamo u av strukturu vidimo sledece: ------------code snip --------------------- INTERNAL_SIZE_T max_fast; /* low 2 bits used as flags */ /* Fastbins */ mfastbinptr fastbins[NFASTBINS]; /* Base of the topmost chunk -- not otherwise kept in a bin */ mchunkptr top; /* The remainder from the most recent split of a small request */ mchunkptr last_remainder; ------------/code snip --------------------- Znaci max_fast je ispred fastbins sto je ustvari niz pokazivaca na fastbinove. Za te pointere potreban je fastbin index koji se izracunava ovako: /* offset 2 to use otherwise unindexable first 2 bins */ #define fastbin_index(sz) ((((unsigned int)(sz)) >> 3) - 2) Ovo je napravljeno s znanjem da je najmanjia moguca vrednost size polja 16. Sto bi u svim normalnim uslovima bilo tacno. Ali, kako mi kontrolisemo size polje chunka koji free() procesira mozemo u njega da stavimo manju vrednost. Sta se desava kada stavimo 8? fastbin_index(8) je dakle 8 >>3 -2 8>>3 daje 1 , a 1 - 2 je -1. Stoga se adresa tog chunka, tacnike fb pointer upisuje na u fastbins[-1], a kako je max_fast upravo na toj adresi dolazi do malog korumpiranja koji je nama neophodan. E sad, ajde da napravi mola programcic koji radi upravo ovo: -------prime.c---------- main(int argc, char **argv) { char *a; char *b; char *p; char *x; int i; a = (char *)malloc(0); //alociran buffer od 16 bajta p = a - 8; // pointer na pocetak chunka, a pokazuje na pocetak podataka b = a; // pokazivac pokazuje na a, da bi sacuvali pravu vrednost a b = b-4; // sada b pokazuje na size polje gore alociranog chunka *b = 8 ; // postavlja vrednost size polja na 8 printf("Chunk is at :0x%x\n",p); //info printf("Actual mem is at: 0x%x\n",a); //info printf("It`s size is:0x%x\n",*b); //info free(a); } --------/prime.c----------- I kad ga pokrenemo: bash-3.00$ gcc prime.c -o prime bash-3.00$ ./prime Chunk is at :0x8049730 Actual mem is at: 0x8049738 It`s size is:0x8 *** glibc detected *** free(): invalid next size (fast): 0x08049738 *** Aborted bash-3.00$ Aha, zaboravili smo na onaj test. Kako vec imamo korumpirani chunk nije problem i ovaj test da zaobidjemo. Samo treba da na adresu p + size + 4 upisemo odgovarajucu velicinu da bi test prosao. Dodajmo to u program: -------prime.c---------- main(int argc, char **argv) { char *a; char *b; char *p; char *x; int i; a = (char *)malloc(0); //alociran buffer od 16 bajta p = a - 8; // pointer na pocetak chunka, a pokazuje na pocetak podataka b = a; // pokazivac pokazuje na a, da bi sacuvali pravu vrednost a b = b-4; // sada b pokazuje na size polje gore alociranog chunka *b = 8 ; // postavlja vrednost size polja na 8 printf("Chunk is at :0x%x\n",p); //info printf("Actual mem is at: 0x%x\n",a); //info printf("It`s size is:0x%x\n",*b); //info b = p+8+4; // dodatak - sada b pokazuje na size polje sledeceg, laznog, chunka *b = 0x10; // dodatak - size laznog sledeceg chunka je 16 ili 0x10 hex free(a); } --------/prime.c----------- Pokrenuto : bash-3.00$ gcc prime.c -o prime bash-3.00$ ./prime Chunk is at :0x8049740 Actual mem is at: 0x8049748 It`s size is:0x8 bash-3.00$ Sada sve prolazi, a mi imamo korumpiranu av->max_fast varijablu. Sad dolazimo do dela zbog kojeg ja nisam mogao da napisem PoC za ovu tehniku. Da bi od prepisivanja av->max_fast varijable dosli do pokretanja naseg shellcodea House Of Prime prpisuje arena_key strukturu. I najbitnije je da se arena_key nalazi na visoj adresi od same arena strukture. Sto kod mene nije bio slucaj. Nego sta meozemo. Da bi prepisali arena_key treba nam onaj drugi free() poziv i fastbin kod se opet upotrebljava. Posto smo mi prethodno prepisali av->max_fast adresom naseg prvog buffera sada ce fastbin kod da se koristi i za jako velike chunkove. Opet koristimo ono isto mesto za prepisivanje. Upisujemo vrednost u av->fastbins[]. To mozemo da upisemo na najvecu vrednost od av->fastbins[fastbin_index(av->max_fast]) sto je verovatno dovljno da bi se dostigla arena_key i prepisala, naravno ako se nalazi na visoj adresi. Radi objasnjenja koristicu vrednosti koje je phantasmal koristio u svom tekstu. Kod njega je arena_key bila na 1156 bajta od av->fastbins[0]. Da bi prepisali arena_key sa fb potreban je fasbin sa indeksom 1156/sizeof(mchunkpointer). Kako se raid o 32bitnim sistemima to je indeks od 289. fastbin_index(289) daje dakle, ako preokrenete izracunavanja, (289 + 2) << 3 = 2328. Znaci , druigi chunk treba da ima size polje od 2328 bajta da bi se adresa fb upisala na arena_key. Jedna stvar je ovde jako bitna. Da bi uspesno dosli do pokretanja shellcodea potrebno je da napadac kontrolise sadrzaj drugog chunka, jer ce on uskoro postati nova arena... Sada dolazimo do onog malloc() poziva koji nam je bio potreban. Poziv za malloc() je u stvari warper za public_mALLOc. Tu nam je najbitnija stvar get_arena() makro. On je zaduzen za nalazenje arene za chunk. To radi preko arena_key. Posto je arena_key vec prepisan adresom naseg drugog korumpiranog chunka, ar_ptr sada sadrzi tu adresu i biva prosledjen _int_malloc() funkciji. Odatle pa nadalje pahtansma phantasmagoria predstavlja dva nacina za dolazenje do shellcodea. Jedan koristeci fasbin kod i drugi koristeci unsorted_chunks kod. Idemo prvo fastbin kodom. Sada av sadrzi adresu naseg drugog korumpiranog chunka. Posto je ovo sada nealoocirani chunk. p->fd je u stvari av->fastbins[0]. A p->size je ustvari av->maxfast. Ovo oznacava da zahtev za memorijom koji ovaj malloc() poziv trazi mora biti manji od size polja drugog korumpiranog chunka sto je u stvari 2328. Ako ovaj uslov ne moze biti ispunjen mora se koristiti unsorted_chunks kod. Sada je potrebno postaviti lazan fastbin unos na av->fastbins[fasbin_index(nb)] (nb je velicina zahteva koji ovaj malloc poziv zahteva). Kako na to mesto mozemo upisati bilo koju vrednost, mozemo staviti neku vrednost koja jse nalazi na steku. Tj na neku varijablu koja je pod kontrolom napadaca. Bitno je samo da svi testovi koji se tu vrse prodju, sto u glavnom zavisi od toga da vrednosti te varijavle odgovaraju vrednostima koje malloc() ocekuje, sto i nije tako tesko ispuniti. Tacnije taj lazni chunk mora da ima isti fastbin_index() kao i nb. I sad, malloc ce taj deo memorije steka procesirati isto kao da je regularni chunk, a ako se tu blizu nalazi sacuvana ret adresa ili ti EIP, ako je dovoljno blizu, napadac je poze prepisati nekom vrednoscu sto dovodi do samog shellcodea. Ni meni nije u potpunosti najjasnije kako bi se ovo izvelo bez proof of concept exploita. Tako da mi je jako zao sto sad ne mogu da ga napisem i sam se uverim kako to sve radi ali bice valjda. No ajmo sad na taj unsorted_chunks put. Dakle, sam phantasmal kaze da je, ako je moguce pozvati malloc sa zahtevom vecim od drugog korumpiranog chunka koji smo predali free(), mnogo bolje koristiti unsorted_chunks kod. Da bi uopste dosli do tog dela koda, potrebno je da zahtev bude veci od 512 i narano veci od korumpirane vrednosti av->max_fast lazne nove arene. Sto sada i nije takav problem jer kontorlisemo sadrzaj drugog chunka koji u stvari JESTE ta lazna arena. Stoga je potrebna malo veca kontorla sadrzaja drugog chunka kao i kontorla nad dve memorijske lokaciju unutar adresnog prostora procesa koji exploitujemo. Sad , bacimo pogled na taj unsorted_chunks kod: ------------code snip --------------------- for(;;) { while ( (victim = unsorted_chunks(av)->bk) != unsorted_chunks(av)) { bck = victim->bk; [1] if (__builtin_expect (victim->size <= 2 * SIZE_SZ, 0) || __builtin_expect (victim->size > av->system_mem, 0)) malloc_printerr (check_action, "malloc(): memory corruption", chunk2mem (victim)); size = chunksize(victim); /* If a small request, try to use last remainder if it is the only chunk in unsorted bin. This helps promote locality for runs of consecutive small requests. This is the only exception to best-fit, and applies only when there is no exact fit for a small chunk. */ if (in_smallbin_range(nb) && bck == unsorted_chunks(av) && victim == av->last_remainder && (unsigned long)(size) > (unsigned long)(nb + MINSIZE)) { ... } ... /* remove from unsorted list */ unsorted_chunks(av)->bk = bck; bck->fd = unsorted_chunks(av); /* Take now instead of binning if exact fit */ if (size == nb) { set_inuse_bit_at_offset(victim, size); if (av != &main_arena) victim->size |= NON_MAIN_ARENA; check_malloced_chunk(av, victim, nb); return chunk2mem(victim); } ... ------------/code snip --------------------- Prvo sto se ovde desava jeste da unsorted_chunks() mozemo da kontorlisemo jer se odnosi na sadasnju nasu laznu arenu, odnosno na drugi chunk koji smo predali free(). Znaci, unsorted_chunks() makro vraca av->bins[0] sto mi kontrolisemo. Tu treba da se nalazi adresa nekog dela memorije koji je pod kontrolom napadaca, radi objasnjavanja ovaj deo memorije zovemo A. Znaci u gornjem kodu victim mozemo da postavimo za vrednost A tako sto av->bins[0] postavimo laznu adresu nekog dela memorije, na steku recimo. A treba da ima oblik nealociranog chunka naravno i A->bk treba da sadrzi adresu koju ce posle toga da dobije victim. Ta adresa je adresa druge lokacije u memoriji koja je pod kontrolom napadaca i naziva se B.Posto napadac kontrolise vrednosti u B , bck se postavlja na adresu B->bk. Da bi se lagano prosli testovi koji slede phantasmal preporucuje da B->size bude isto kao i nb. Kako smo u mogucnosti da postavimo bck na bilo koju adresu koju pozelimo [1] i kako unsorted_chunks() idalje vraca vrednost koju mi zelimo sada mozemo da bck->fd [2] postavimo na bilo koju adresu do A. Onda jednostavno bck postavimo za adresu neke funkcije u GOT ili .dtors sekciju - 8 sto preusmerava tok programa na A->prev_size gde bi morao da se nalazi short jump da se preskoci A->bk i to je to. Poziv se dalje normalno zavrsava, malloc() vraca B i pri sledecm pozivu prepisane adrese funkcije u GOT ili pri izlasku programa dolazi do izvrsenja shellcodea. Kao sto vidite, nije da ima mnogo uslova u ovoj tehnici, nego je nekako realno tesko zamislivo da mozete da kontrolisete sve ove stvari u nekoj real life aplikaciji, tj da ce neka real life aplikacija da pruzi ovakve mogucnosti. Koliko ja vidim , pored ovih stvari sa free() i malloc() pozivima najveci problem predstavljaju ova dva mesta u memoriji A i B. Ako se radi o lokalnom eksploitovanju pretpostavljam da bi environment varijable mogle da se koriste kao u stack eksploatacije kada shellcode stavljate u varijablu okruzenja. Toliko od mene za sada o House Of Prime. 05.2 - House Of Mind HoM zahteva samo jedan poziv free() da bi funkcionisala. Stoga je najbliza staroj unlink() tehnici. Nekako je od svih kuca u malloc maleficarumu najgeneralnija. Provo pocnimo s opisivanjem tehnike i uporedo pisanjem Proof of Concept ranjivog programa i exploita za isti.