Base issue is that when handling a file upload (two locations do this) the buffer is allocated based on Content-Length, but the memcpy is based on the actual payload length. Creating a heap overflow.

Exploitation is where things get a bit more interesting. They do a fd (forward) pointer overwrite on fastbin. Idea being you overwrite that pointer so that when you free, first it’ll give you the corrupted block, and then it’ll set that fd pointer as the head of the fastbin, and give you that as a next block.

However this won’t work in the original location because it always does a free before the alloc taking over the head of the fastbin. The second location for it, /genierestore.cgi could work except it triggers a malloc(0x1000) beforehand which triggers a malloc_consolidate which properly frees all the fastbins. So they first do a targeted overwrite of the heaps max_fast value.

This happens because the malloc_state structure has the max_fast value immediately preceding the fastbin array. When assigning a new block into the fastbin it’ll call fastbin_index(size) to get the index to the fastbin to write to. If you corrupt the size though it’ll return -1, writing to fastbins[-1] which happens to be max_fast.

Once overwritten they can use the genierestore.cgi page and target the fastbin fd pointer, overwrite it and get a chunk pointing to the GOT entry for system.