Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 12:43:23 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/binary-exploitation/heap/unsorted-bin-attack.md
CPol 0eb22426a0
GITBOOK-4340: No subject
2024-05-17 15:37:03 +00:00

7.6 KiB
Raw Blame History

Unsorted Bin Attack

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

Other ways to support HackTricks:

Basic Information

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.

{% hint style="success" %} 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. {% endhint %}

{% hint style="danger" %} 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. {% endhint %}

References & Other examples

  • https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#hitcon-training-lab14-magic-heap
    • The goal is to overwrite a global variable with a value greater than 4869 so it's possible to get the flag and PIE is not enabled.
    • It's possible to generate chunks of arbitrary sizes and there is a heap overflow with the desired size.
    • The attack starts creating 3 chunks: chunk0 to abuse the overflow, chunk1 to be overflowed and chunk2 so top chunk doesn't consolidate the previous ones.
    • Then, chunk1 is freed and chunk0 is overflowed to the bk pointer of chunk1 points to: bk = magic - 0x10
    • Then, chunk3 is allocated with the same size as chunk1, which will trigger the unsorted bin attack and will modify the value of the global variable, making possible to get the flag.
  • https://guyinatuxedo.github.io/31-unsortedbin_attack/0ctf16_zerostorage/index.html
    • The merge function is vulnerable because if both indexes passed are the same one it'll realloc on it and then free it but returning a pointer to that freed region that can be used.
    • Therefore, 2 chunks are created: chunk0 which will be merged with itself and chunk1 to prevent consolidating with the top chunk. Then, the merge function is called with chunk0 twice which will cause a use after free.
    • Then, the view function is called with index 2 (which the index of the use after free chunk), which will leak a libc address.
    • As the binary has protections to only malloc sizes bigger than 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.
    • Then, it's possible to call the edit function with the index 2 (the use after free pointer) and overwrite the 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.
    • Now a fast bin attack is performed:
      • First of all it's discovered that it's possible to work with fast chunks of size 200 in the __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
        • If we manage to get a fast chunk of size 0x200 in this location, it'll be possible to overwrite a function pointer that will be executed
      • For this, a new chunk of size 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.
      • Then, the edit function is called in this chunk to modify the fd address of this fast bin to point to the previous __free_hook function.
      • Then, a chunk with size 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.
      • And finally a chunk containing the string /bin/sh\x00 is freed calling the delete function, triggering the __free_hook function which points to system with /bin/sh\x00 as parameter.
Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

Other ways to support HackTricks: