This one is a nice demo of what we learned Monday, just one step removed from a win function.
Extra Challenge Question for you: How is this done in the 64-bit case?
Linking Libraries and Address Randomization
Parts of the story I want to tell:
memory segments
PIE and ASLR
GOT and PLT
glibc is Wal-mart
Part 1: Memory Segments
Let's take any program, run it and get a pid, then inspect
/proc/:pid/maps
You can use a syscall mmap to request a new segment or alter
the permissions of an existing segment (yes PWNs are possible with that).
The key segments that tend to exist all of the time are:
The instructions (.text segment)
Initialized Data (.data)
Uninitialized Data (.bss)
The Stack
The Heap (once malloc has been called)
Library Segments (typically for glibc, sequential, with various permissions)
PIE and ASLR
So now it's not too hard to say what these do:
PIE makes it so that the instruction (.text) segment is randomized at each instance of the program running.
ASLR makes the other segments randomized each execution of the program
These are both security measures to make it harder on PWNers.
Let's do a demo:
Let's run this a few times, turn off the PIE and run it a few more times.
This opens up some big questions, if the binary never changes a single byte of it's code and
cool functions live inside of glibc then how do we access printf reliably?
GOT PLT Lazy Linking
My analogy version of this is a little bit like a librarian (the linker) who knows where to find what you need.
If your executable is a book then at the back of the book is the phone number for the libarian.
That librarian will take requests and can be found reliably by you. Then the librarian brings
you the book open to a particular page that you can now reference whenever you need.
So I'm going to go through some examples and we'll talk out all of the details
how exactly your binary looks up the locations of external library functions.
Here are the talking points followed by some screenshots that I might want to refer to. But this lecture
will mostly be video based not text based.
Walk through 3baby_boi
Let's step through the PLT lazy-linking process.
The idea is to "memoize" the first expensive library address lookup.
When we do call sym.imp.func1 the address it jumps to is the PLT address for func1 which is in a
contiguous segment (with R-X permissions) from the machine code at some fixed offset
The first line (of only 3 lines) at that address in the PLT part is a JUMP to the address stored in the GOT segment for func1, always.
This segment gets populated in the beginning of the program and the first value if populates with is actually line 2 of the PLT!?!? so the first jump is actually just a one line progression as if there were no jump... cute
All futures times will jump to some other address so these next 2 lines only run once
a fixed value is pushed into the stack then the dynamic linker is called
That linker identifies the address of the desired library function and stores that address in the address inside the GOT table (and then send you to that address)
All future call sym.imp.func1 first jump to the address stored in GOT which will now directly be the correct op codes from the library
(BTW: FULL RELRO means we do the entire PLT process for all imported library functions in advance so that the GOT table can be truly read-only)
The GOT table raw
How to print an address from memory
The ops of the linker (i.e. let's NOT dissect that)
glibc is Wal-Mart
So I would like to do a whole lecture on this.
But once you have a single leak you can calculate beginning of the glibc address,
then use known offsets to find the exact address of cool stuff.
Here is a useful pwntools demo that gives us a few nice tricks: a list of every glibc symbol we can use, a trick for using a leak to get a base address, a trick for leaning on that to get correct addresses (despite randomization):
