Don't like this style? Click here to change it! blue.css
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:
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.
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
0x7fdac760. Use https://libc.rip/ to find the exact glibc on that server.
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.
lddon the binary and see the EXACT names of the library and the linker that it wants to link to
patchelf --set-interpreter ./ld-linux-x86-64.so.2 --set-rpath . binaryname
Do PCP 23