return address overwrite. Add secret value before return address Verify the value before jumping to return address First described in 1998 Introduced in GCC and MSVC in 2003. Return Address VAR0 VAR1 … … 0xF000 0xE000 Stack Cookie
Mark memory pages as non-executable by default. Protections always existed, just not enforced. New hardware development. Mainstream Windows & Linux support in 2004.
and locating their own malicious payload. Randomize load locations of libraries and the program image. Randomize stack addresses Randomize heap addresses
Exception Handler Cause an Exception Locate API Addresses Locate Shellcode Create Fake Stack Frame to Execute Code Execute Shellcode Escape from sandbox Complete Compromise
Exception Handler Cause an Exception Locate API Addresses Locate Shellcode Create Fake Stack Frame to Escape from Sandbox Create Stack Frame to Disable Code Signing Execute Shellocde Complete Compromise
overflow stuff on Windows Let’s look at some of the telltale signs of stack canaries What are some ways that you could do a stack canary incorrectly? Would this be an amusing CTF challenge? What is the concept that this all reduces to?
Overwrites Function Pointer Shellcode Need stack pivot (control of address to control of stack) Persist Knowledge: Location of stack pivot (static, if it exists) Memory Layout (relatively static) Writeable Address (data section) Function Pointer (static via import table) Bugs Needed: 1-2
too big to show here, but its really really hard. Hope for application data overwrite or a function pointer overwrite. C++ objects come with a lot of function pointers.
problems Having contestants attack real-world software would be Boring Very very difficult Too much like real work Upside: Don’t have to work through ginormous attack trees Downside: exploiting is more solving a “puzzle” that is mostly in the head of the problem author
a crashing input and a desire to get a shell Use a debugger Write things down and draw diagrams Account for things you know about the conditions in the target program In the real world, we don’t like to leave things to chance In CTF, 60% of the time, it works every time Now is better than later
script that produces the crash Describe as much as you can, to yourself, about how input data reacts with the vulnerable program Work iteratively to get control over crashes Vulnerability identification is generally a solo activity, exploit development can be more conductive to pairing up
object was being acted upon? How much control do I have over the source / destination? What objects are adjacent to where I can control reading / writing?
theme Find a way to write into something you shouldn’t Find how to connect that write to some code sequence that does what you want If no single primitive exists to do last two, find composition of primitives that does If no such combination of primitive exists either You are looking at the wrong thing You are not doing CTF and have started doing this for a living. My condolences