Pointer Redirecting

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks

String pointers

If a function call is going to use an address of a string that is located in the stack, it’s possible to abuse the buffer overflow to overwrite this address and put an address to a different string inside the binary.

Ako će, na primer, poziv funkcije koristiti adresu stringa koja se nalazi na steku, moguće je iskoristiti buffer overflow da se prepiše ta adresa i ubaci adresa drugog stringa u binar.

If for example a system function call is going to use the address of a string to execute a command, an attacker could place the address of a different string in the stack, export PATH=.:$PATH and create in the current directory an script with the name of the first letter of the new string as this will be executed by the binary.

Ako će, na primer, poziv funkcije system koristiti adresu stringa za izvršavanje komande, napadač može postaviti adresu drugog stringa na stek, izvršiti export PATH=.:$PATH i kreirati u trenutnom direktorijumu skript čije je ime prvo slovo novog stringa, jer će ga binar izvršiti.

In real targets, repointing a stack string pointer is usually more interesting than just changing the printed text:

  • Redirect a later system/popen/execl* argument to an existing "/bin/sh" or attacker-controlled command string already present in memory.
  • Redirect a later read sink such as puts("%s", ptr) or write(fd, ptr, len) to leak stack, heap or binary data.
  • Redirect a later write sink such as strcpy(dst, ...), memcpy(dst, src, len), or a structure field assignment through ptr->field = value to turn the stack overflow into a second-stage arbitrary write.

Na realnim ciljevima, preusmeravanje pokazivača na string na steku obično je zanimljivije od same promene prikazanog teksta:

  • Preusmerite kasniji argument system/popen/execl* na postojeći "/bin/sh" ili na string komande pod kontrolom napadača koji je već u memoriji.
  • Preusmerite kasniji read sink kao što je puts("%s", ptr) ili write(fd, ptr, len) da bi se leak-ovali podaci sa steka, heapa ili binara.
  • Preusmerite kasniji write sink kao što su strcpy(dst, ...), memcpy(dst, src, len) ili dodela polja strukture preko ptr->field = value kako biste stack overflow pretvorili u second-stage arbitrary write.

When auditing, prioritise stack locals such as char *cmd, char *path, char *buf, FILE *fp, or pointers inside temporary request/response structs that are used after the overflow but before the function returns. This is especially useful when the overflow cannot safely reach the saved return address because of a canary or because corrupting a nearby pointer is enough.

Prilikom auditovanja, dajte prioritet lokalnim promenljivama na steku kao što su char *cmd, char *path, char *buf, FILE *fp, ili pokazivačima unutar privremenih request/response struktura koji se koriste posle overflow-a ali pre nego što funkcija vrati. Ovo je posebno korisno kada overflow ne može bezbedno da dosegne sačuvanu return adresu zbog canary-ja ili zato što je korupcija susednog pokazivača dovoljna.

If the corruption is limited to a partial overwrite (for example because the bug appends a 0x00), try to redirect the pointer to:

  • A nearby string in the same stack frame
  • Another object in the same module / non-PIE image
  • A controlled region whose high bytes stay unchanged

Ako je korupcija ograničena na partial overwrite (na primer zato što bug dodaje 0x00), pokušajte da preusmerite pokazivač na:

  • String u blizini u istom stack frame-u
  • Drugi objekat u istom modulu / non-PIE image
  • Kontrolisanu oblast čiji se viši bajtovi ne menjaju

For the related ASLR-oriented case where a trailing NUL modifies an existing stack pointer instead of a dedicated local variable, check Ret2ret & Reo2pop.

Za povezani ASLR-smerni slučaj u kojem trailing NUL menja postojeći stack pointer umesto namenski lokalne promenljive, pogledajte Ret2ret & Reo2pop.

You can find an example of this in:

Primer možete naći u:

Function pointers

Same as string pointer but applying to functions, if the stack contains the address of a function that will be called, it’s possible to change it (e.g. to call system).

Isto kao i kod string pokazivača, ali primenjivo na funkcije: ako stek sadrži adresu funkcije koja će biti pozvana, moguće ju je promeniti (na primer da se pozove system).

Useful targets are not only explicit callback variables such as void (*fp)(). In practice, look for:

  • Callbacks stored in local structs passed later to helper functions
  • Destructor / cleanup handlers invoked on error paths
  • Parser dispatch tables or state-machine handlers copied to the stack
  • Local structs / objects that later dispatch through an indirect call

Korisni ciljevi nisu samo eksplicitne callback promenljive poput void (*fp)(). U praksi, tražite:

  • Callbacks uskladištene u lokalnim strukturama koje se kasnije prosleđuju pomoćnim funkcijama
  • Destructor / cleanup handlers pozvane na error putanjama
  • Parser dispatch tables ili state-machine handlers kopirane na stek
  • Lokalne strukture / objekti koji kasnije izvršavaju indirektni poziv

In modern exploitation, pointer redirection is often the last primitive available before touching the canary. A 2024 exploitation writeup for CVE-2024-20017 shows the typical pattern: the overflow reaches several local variables before the stack canary, the attacker corrupts a stack pointer plus its associated length/value, and a later assignment through that pointer becomes an arbitrary write without ever needing to return through the corrupted frame.

U modernoj eksploataciji, pointer redirection često je poslednji primitiv dostupan pre nego što se dira canary. Writeup iz 2024. za CVE-2024-20017 prikazuje tipičan obrazac: overflow dostiže nekoliko lokalnih promenljivih pre stack canary-ja, napadač korumpira stack pokazivač plus pridruženu dužinu/vrednost, i kasnija dodela kroz taj pokazivač postaje arbitrary write bez potrebe da se vraća kroz korumpirani frame.

Pointer corruption to second-stage primitives

If a nearby pointer is later dereferenced for a store, the goal is usually not to jump directly with the first overflow, but to upgrade the primitive:

  1. Overflow a local buffer and corrupt a pointer plus any associated length / integer / index.
  2. Wait for the function to perform a post-overflow dereference such as ptr->len = x, memcpy(ptr, src, n) or *ptr = value.
  3. Use that resulting write-what-where to overwrite a GOT slot, callback, config pointer, or another indirect callsite.

Ako se susedni pokazivač kasnije dereferencira za upis, cilj obično nije odmah skočiti sa prvog overflow-a, već nadograditi primitiv:

  1. Preliti lokalni buffer i korumpirati pokazivač plus bilo koju pridruženu dužinu / integer / indeks.
  2. Sačekati da funkcija izvrši post-overflow dereferencu kao što je ptr->len = x, memcpy(ptr, src, n) ili *ptr = value.
  3. Iskoristiti dobijeni write-what-where da prepišete GOT slot, callback, config pokazivač ili drugo indirektno mesto poziva.

This is a good option when:

  • The bug stops at the canary
  • The function pointer itself is not directly reachable
  • A 4-byte or 8-byte data write is easier to get than an immediate control-flow hijack

Ovo je dobra opcija kada:

  • Bug staje na canary-ju
  • Sam funkcijski pokazivač nije direktno dostupan
  • Je lakše ostvariti 4-byte ili 8-byte data write nego trenutni hijack kontrolnog toka

The same idea also works for read primitives if the corrupted pointer is later passed to logging, printing, or network send helpers.

Ista ideja radi i za read primitivе ako se korumpirani pokazivač kasnije prosledi helper-ima za logovanje, štampanje ili slanje preko mreže.

Modern AArch64 note: PAC / BTI

On current AArch64 targets, a classic saved return address overwrite may fail because the epilogue authenticates x30 with PAC. In those cases, non-return hijacks such as corrupted local function pointers or callback pointers become more attractive.

Međutim, ako BTI je enabled, the overwritten indirect-call target must still land on a valid landing pad (typically a function entry with bti c, or in PAC-enabled code a prologue starting with paciasp/pacibsp). Therefore, when redirecting a stack function pointer on AArch64, prefer:

  • Real function entries instead of mid-function gadgets
  • Targets whose prologue already satisfies BTI
  • Targets where the indirect-call pointer is not additionally authenticated before use

Za trenutne AArch64 ciljeve, klasično prepisivanje sačuvane return adrese može propasti jer epilog autentifikuje x30 pomoću PAC. U tim slučajevima, non-return hijack kao što su korumpirani lokalni funkcijski pokazivači ili callback pokazivači postaju privlačniji.

Međutim, ako je BTI omogućen, prepisana indirektna meta poziva mora i dalje da sleti na validan landing pad (obično ulaz funkcije sa bti c, ili u PAC-om zaštićenom kodu prolog koji počinje sa paciasp/pacibsp). Stoga, pri preusmeravanju stack funkcijskog pokazivača na AArch64, preferirajte:

  • Prave ulaze funkcija umesto mid-function gadget-a
  • Ciljeve čiji prolog već zadovoljava BTI
  • Ciljeve gde indirektni pokazivač poziva nije dodatno autentifikovan pre upotrebe

For a related AArch64 stack-overflow context, check ret2win-arm64.

Za povezani AArch64 stack-overflow kontekst, pogledajte ret2win-arm64.

You can find an example in:

Primer možete naći u:

References

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks