patchelf and custom glibcs

AKA glibcs everywhere

This is something I would not have spent a whole lecture on before, but it is MISSION CRITICAL that you are good at this particular skill.

Heap exploits are VERY sensitive to which version of GLIBC you use.

So stage 1 to most advanced exploits in this area involves:

• Know/discover which version of libc the server uses
• Get a copy of that exact libc and the linker for that libc
• patch your binary to the correct libc
• Confirm it's wired correctly

Motivation for this skill

AKA how2heap

Take a look at the beautiful repository How2Heap and scan the index of exploits and tricks.

Observe the difference in tcache_poisoning between 2.31 and 2.31.

For this particular exploit, of doing a write what where. In old glibcs you just write your target to the chunk and go. In modern glibcs you must first learn a heap leak THEN write target ^ (chunk_address >> 12) to the chunk... Huge difference and really important to get right before targeting some poor server.

Discovering the glibc

Most problems will send you their exact glibc as a file named libc.so.6 or something similar.

If NOT then look for a Dockerfile with the problem and you can find the glibc that launched with that container.

If you don't have a dockerfile (or other text hint) try to find a LEAK based on your local exploiting (we've done this a couple times already). Then use https://libc.rip/ to take the last 3 characters of the leak and hunt for a matching glibc.

Suppose I've leaked the address of printf in a 32-bit binary and the leak was 0x7fdac760. Use https://libc.rip/ to find the exact glibc on that server.

glibc_all_in_one

At the top of how2heap they have a link to glibc_all_in_one which is a nice quick way to fetch and download the files for any glibc.

Follow the README and fetch the glibc (and linker) from the previous example

I'll do a live demo.

PATCHING your glibc

• run ldd on the binary and see the EXACT names of the library and the linker that it wants to link to
• move your glibc and linker from the previous step to match those EXACT NAMES (presuming ld-linux-x86-64.so.2 for examples)
• patchelf --set-interpreter ./ld-linux-x86-64.so.2 --set-rpath . binaryname
• move unneeded files out of the . directory
• (It helps if the binary is compiled with that glibc or newer...)

Do PCP 23