old FSOP Exploits

Just for reference here are our struct treasure maps:

The story is roughly like this:

glibc keeps a singly-linked-list of filestreams
the head of this list is _IO_list_all
the filestreams are officially type: _IO_FILE_plus
the _IO_FILE_plus is just a thin struct that wraps an _IO_FILE and an struct _IO_jump_t* (pointer to a jump table)
the _chain attribute is a pointer to the next filestream.
there are ALWAYS stderr, stdout, and stdin in our linked list when we start the program

By the way you can inspect these things in gdb as follows:

possible objective 1: vtable hijacking

So the jump_table is a struct full of function pointers.

This is needed for object-oriented coding.

If you can overwrite a function pointer inside the vtable of a filestream then trigger that function you can control the instruction pointer.

possible objective 2: arbitrary reading

When a filestream flushes it's buffers it will stream from the ptr to the end of the stream. If we control those addresses we can get arbitrary reads.

possible objective 3: arbitrary writes

Likewise if we take over stdout and can carefully control pointers we can dump a buffer into a region.

Various gotchas

_IO_flush_all_lockp
vtable validation
how and when to trigger

From our perspective this is a target rich topic, but a little light on blog-posts and articles and pretty pictures. We'll have to forge our own path. Exciting!

FSOP Playground and tricks draft 1

I'll be updating this as we go for sure, but I'd like to start with an FSOP playground for making a fake _IO_FILE_plus and linking it into the _IO_list_all:

Playground Exploit 1

OK So let's make an exploit together using this playground.

The idea is to create a fake vtable (_IO_jump_t) and predict/leak it's address
Then to create a fake file stream (_IO_FILE_plus)
Put the address of the fake vtable 216 bytes into the fake file stream
Our first strategy is _IO_flush_all_lockp and OVERFLOW
There's one more check we need to pass but let's find it together using debugging and source code

The OVERFLOW check

OK so we're going to play with this live. But once you're here the check is this:

_mode must by less than or equal to zero
the write_ptr must be greater than the write_base

To control the _mode write_ptr and write_base we need some treasure map offsets.