7.9 KiB
House of Roman
Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!
Other ways to support HackTricks:
- If you want to see your company advertised in HackTricks or download HackTricks in PDF Check the SUBSCRIPTION PLANS!
- Get the official PEASS & HackTricks swag
- Discover The PEASS Family, our collection of exclusive NFTs
- Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
- Share your hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.
Basic Information
This was a very interesting technique that allowed for RCE without leaks via fake fastbins, the unsorted_bin attack and relative overwrites. However it has ben patched.
Code
- You can find an example in https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_roman.c
Goal
- RCE by abusing relative pointers
Requirements
- Edit fastbin and unsorted bin pointers
- 12 bits of randomness must be brute forced (0.02% chance) of working
Attack Steps
Part 1: Fastbin Chunk points to __malloc_hook
Create several chunks:
fastbin_victim
(0x60, offset 0): UAF chunk later to edit the heap pointer later to point to the LibC value.chunk2
(0x80, offset 0x70): For good alignmentmain_arena_use
(0x80, offset 0x100)relative_offset_heap
(0x60, offset 0x190): relative offset on the 'main_arena_use' chunk
Then free(main_arena_use)
which will place this chunk in the unsorted list and will get a pointer to main_arena + 0x68
in both the fd
and bk
pointers.
Now it's allocated a new chunk fake_libc_chunk(0x60)
because it'll contain the pointers to main_arena + 0x68
in fd
and bk
.
Then relative_offset_heap
and fastbin_victim
are freed.
/*
Current heap layout:
0x0: fastbin_victim - size 0x70
0x70: alignment_filler - size 0x90
0x100: fake_libc_chunk - size 0x70 (contains a fd ptr to main_arena + 0x68)
0x170: leftover_main - size 0x20
0x190: relative_offset_heap - size 0x70
bin layout:
fastbin: fastbin_victim -> relative_offset_heap
unsorted: leftover_main
*/
-
fastbin_victim
has afd
pointing torelative_offset_heap
-
relative_offset_heap
is an offset of distance fromfake_libc_chunk
, which contains a pointer tomain_arena + 0x68
- Just changing the last byte of
fastbin_victim.fd
it's possible to makefastbin_victim points
tomain_arena + 0x68
For the previous actions, the attacker needs to be capable of modifying the fd pointer of fastbin_victim
.
Then, main_arena + 0x68
is not that interesting, so lets modify it so the pointer points to __malloc_hook
.
Note that __memalign_hook
usually starts with 0x7f
and zeros before it, then it's possible to fake it as a value in the 0x70
fast bin. Because the last 4 bits of the address are random there are 2^4=16
possibilities for the value to end pointing where are interested. So a BF attack is performed here so the chunk ends like: 0x70: fastbin_victim -> fake_libc_chunk -> (__malloc_hook - 0x23)
.
(For more info about the rest of the bytes check the explanation in the how2heap example). If the BF don't work the program just crashes (so start gain until it works).
Then, 2 mallocs are performed to remove the 2 initial fast bin chunks and the a third one is alloced to get a chunk in the __malloc_hook:
malloc(0x60);
malloc(0x60);
uint8_t* malloc_hook_chunk = malloc(0x60);
Part 2: Unsorted_bin attack
For more info you can check:
{% content-ref url="unsorted-bin-attack.md" %} unsorted-bin-attack.md {% endcontent-ref %}
But basically it allows to write main_arena + 0x68
to any location by specified in chunk->bk
. And for the attack we choose __malloc_hook
. Then, after overwriting it we will use a relative overwrite) to point to a one_gadget
.
For this we start getting a chunk and putting it into the unsorted bin:
uint8_t* unsorted_bin_ptr = malloc(0x80);
malloc(0x30); // Don't want to consolidate
puts("Put chunk into unsorted_bin\n");
// Free the chunk to create the UAF
free(unsorted_bin_ptr);
Use an UAF in this chunk to point unsorted_bin_ptr->bk
to the address of __malloc_hook
(we brute forced this previously).
{% 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 %}
So, to trigger the write of main_arena + 0x68
in __malloc_hook
we perform after setting __malloc_hook
in unsorted_bin_ptr->bk
we just need to do: malloc(0x80)
Step 3: Set __malloc_hook to system
In the step one we ended controlling a chunk containing __malloc_hook
(in the variable malloc_hook_chunk
) and in the second step we managed to write main_arena + 0x68
in here.
Now, we abuse a partial overwrite in malloc_hook_chunk
to use the libc address we wrote there(main_arena + 0x68
) to point a one_gadget
address.
Here is where it's needed to bruteforce 12 bits of randomness (more info in the how2heap example).
Finally, one the correct address is overwritten, call malloc
and trigger the one_gadget
.
References
- https://github.com/shellphish/how2heap
- https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_roman.c
- https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house_of_roman/
Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!
Other ways to support HackTricks:
- If you want to see your company advertised in HackTricks or download HackTricks in PDF Check the SUBSCRIPTION PLANS!
- Get the official PEASS & HackTricks swag
- Discover The PEASS Family, our collection of exclusive NFTs
- Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
- Share your hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.