Search K
Appearance
Appearance
Other ways to support HackTricks:
When malloc, unsorted lists are able to write the address to unsorted_chunks (av)
in the bk
address of the chunk. Therefore, if an attacker can modify the address of the bk pointer in a chunk inside the unsorted bin, he could be able to write that address in an arbitrary address (maybe in the stack in a variable he can read) which could be helpful to leak a libc addresses.
โ
Taking a look to the example provided in https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle and using 0x4000 and 0x5000 instead of 0x400 and 0x500 as chunk sizes (to avoid tcaches) it's possible to see that nowadays the error malloc(): unsorted double linked list corrupted
is triggered.
Therefore, this unsorted bin attack now (among other checks) also requires to be able to fix the doubled linked list so this is bypassed victim->bck->fd == victim
or not victim->fd == av (arena)
. Which means that the address were we want to right must have the address of the fake chunk in its fd
position and that the fake chunk fd
is pointing to the arena.
โ
Note that this attack corrupts the unsorted bin (hence small and large too). So we can only use allocations from the fast bin now (a more complex program might do other allocations and crash), and to trigger this we must alloc the same size or the program will crash.
bk
pointer of chunk1 points to: bk = magic - 0x10
view
function is called with index 2 (which the index of the use after free chunk), which will leak a libc address.global_max_fast
so no fastbin is used, an unsorted bin attack is going to be used to overwrite the global variable global_max_fast
.bk
pointer to point to p64(global_max_fast-0x10)
. Then, creating a new chunk will use the previously compromised free address (0x20) will trigger the unsorted bin attack overwriting the global_max_fast
which a very big value, allowing now to create chunks in fast bins.__free_hook
location:gefโค p &__free_hook
$1 = (void (**)(void *, const void *)) 0x7ff1e9e607a8 <__free_hook>
gefโค x/60gx 0x7ff1e9e607a8 - 0x59
0x7ff1e9e6074f: 0x0000000000000000 0x0000000000000200
0x7ff1e9e6075f: 0x0000000000000000 0x0000000000000000
0x7ff1e9e6076f <list_all_lock+15>: 0x0000000000000000 0x0000000000000000
0x7ff1e9e6077f <_IO_stdfile_2_lock+15>: 0x0000000000000000 0x0000000000000000
0xfc
is created and the merged function is called with that pointer twice, this way we obtain a pointer to a freed chunk of size 0xfc*2 = 0x1f8
in the fast bin.fd
address of this fast bin to point to the previous __free_hook
function.0x1f8
is created to retrieve from the fast bin the previous useless chunk so another chunk of size 0x1f8
is created to get a fast bin chunk in the __free_hook
which is overwritten with the address of system
function./bin/sh\x00
is freed calling the delete function, triggering the __free_hook
function which points to system with /bin/sh\x00
as parameter.Other ways to support HackTricks: