The following are the decompilations with the function renamed by us, first the main which is a simple switch controller, taking input and routing to the function handlers depending on our input:
This is a generic CRUD style heap pwn where the player are able to perform operations on the heap. In add, we’re able to allocate a chunk with controllable size:
Below the delete function to free allocation, here lies an UAF however due to the nature of the program, we’re unable to perform modification or take advantage of it since there’s flag denoting that the pointer should not be used, still the pointer is left dangling:
Here’s the edit and view function, there’s nothing interesting other than that they check for the used flag to determine if the chunk is freed:
There’s an additional option to resize a chunk, here lies the vulnerability:
If the user specified a size bigger than 0x400, it will error and free the chunk, however it did not update the flag to be not used and didn’t remove the pointer thus resulting an exploitable UAF.
to exploit this we perform the following:
allocate a chunk big enough to be allocated to the unsorted bin for a libc address leak
perform a tcache poisoning to arbitrary allocate to IO_2_1_stdin achieving arbitrary write
corrupt _IO_2_1_stdin_ to gain huge arbitrary write through stdin to corrupt _IO_2_1_stdout_ to gain RCE using FSOP
profit
More details can be inspected by analysing the exploit code below: