A Cutting Edge Exploit

So for the last couple weeks I've been doing my research on glibc 2.34 and what sorts of targets still exist in the world beyond malloc_hook and free_hook.

Next year I'll have to move up to 2.36 which doesn't exist yet. Again this is more of a meta-lesson in security research.

Let's start with the binary I'm trying to exploit:

Actually line 5 is a vestige of a more vulnerable binary I started with but didn't need. You'll see.

Here are all of the files you need to start from square 1: cuttingedge.zip contains glibc 2.34, some source files malloc.c and genops.c, the binary is called pwnme and a starter script with some menu stuff.

Step 1, let's take stalk of our assets:

• We can view chunks after freeing (good for leaks)
• We can edit chunks after freeing (UAF)
• We can malloc chunks of any size
• We can overflow from one chunk to another by 64 bytes (not used here but powerful)

That's actually quite a lot of power in general, and that's because I wanted to concentrate on the glibc protections in the most direct path I could find.

Building Primitives: leaks

Alright so the two classic heap leaks are:

• a chunk address by freeing a couple of tcache sized chunks and viewing the results
• a glibc leak by making a larger chunk (0x420) and a protection chunk (so it doesn't consolidate), freeing and finding our glibc leak

First issue: SAFE LINKING glibc > 2.31

To get out heap leak we have to realize that the data stored in tcache/fastbin chunks has been obscured starting in glibc 2.32.

For that we can use: how2heap decrypt safe-linking

The Python-y version of that looks like:

Here's what tcache chunks look like now-a-days with a fd and key the old fd is actually (intptr_t)((long)fd ^ (long)key >> 12):

My version:

Primitive: GLIBC leak

This is, fortunately very similar to earlier versions. Let's make something big enough to get into the unsorted bins, free it, inspect it, and enjoy our secret data.

SIDE QUEST: Trevor brought me a problem on Monday where this step is non-trivial, and I discovered a whole sub-class of problems where there is no easy leak method.

In that world we can actually do some clever things that are worthy of discussing if you're interested. Here are some good reading links on those kinds of problems:

• House of Rust/Crust (Huge shout out to c4e for helping me in the hunt, wonderful human)
• Sherlock's Babytcache write-up
• TeamRocket's Cancelled write-up

Building Primitives: Write-What-Where

Alright, this is also largely in tact from previous versions, minus the safe-linking issues. In fact, I'm starting to believe that write-what-where might be the easiest part of modern heap exploitations.

In fact the first thing I look for these days is tcache-poisoning: how2heap 2.34 tcache-poisoning

NEW TERMINOLOGY WARNING: Now once you start corrupting tcache bins in order to put whatever you want wherever you want there is a general principle called HEAP FENG SHUI

This is the idea of doing most of your mallocs early in the process before you start to mess the place up. It makes understanding a solution script quite difficult because it's only later that you understand why the early stuff was done.

Here is an example solution script I learned a lot from but is an extreme case of Heap Feng Shui:

The files that go with that solution script (a leakless 2.34 problem) can be found here

Anyhow, here's an example of my WWW for this problem:

Note that I added a second part to the payload to keep the "key" in place, I did this as a good citizen but I think the exploit can work without it.

NEW TARGETING STRATEGY

Now we've got some better assets:

• heap leak
• glibc leak
• a general purpose Write-What-Where

Now what?

Well in all previous years we would use this to write a one_gadget or system into __malloc_hook or __free_hook, but alas our old friends are gone.

So this was a huge part of my research these last few weeks, what are realistic targets in the modern era.

Some promising candidates I haven't fully explored:

Potential Target: glibc's GOT

Yes you heard that right, glibc has it's own relocation table internally, in fact, even when your binary is STATICALLY LINKED!

I haven't finished my research on that approach but here are the subtle rumors I've heard:

• Bowels of GLIBC exploring hidden linking
• A whisper of this idea: "overwriting strlen and other functions in libc got to make a gadget chain and set constraints for a one gadget"

Potential Target: a stack leak then ROP chains!

Who knew that the cutting edge would fully loop back around on itself.

Here's my rumored whisper on this one: "leak a stack pointer by pointing _IO_write_base to the environ symbol"

That's using FSOP as a super-leaker to get back into ROP chains. I think this is actually a really reliable strategy but close enough to the one I did here that I'll just make a note for a future week of research.

OUR TARGET: the stdout vtable, in-place

So my strategy ended up writing the stdout vtable in place and using glibc targets.

Here's the WHY of it:

• Starting in 2.24 the FSOP vtables were checked that they were inside of the glibc segments (i.e. no more fake vtables inside the heap)
• I'm pretty sure the function addresses in the vtable are also checked by segment
• This is called often: IO_validate_vtable
• So we're going to hack them in place using glibc targets

OK I'm out of prep time, here is my exploit script: