Advanced buffer overflow and memory corruption security challenges
Advanced buffer overflow and memory corruption challenges.
INSTRUCTIONS:
For some spoilers read:
http://packetstormsecurity.com/files/121751/Modern-Overflow-Targets.html
or
http://packetstormsecurity.com/files/123977/Bypassing-AddressSanitizer.html
Hints and Challenge Description
Stack Objects - Did you know you could put objects on the stack? -fstack-protector-all prevents you from writing over the stored instruction pointer, but that doesn't mean it prevents all buffer overflows on the stack. Just don't write over the canary...
Heap Objects - Overflowing is a little bit different on the heap. Metadata checks will test the linked list pointers used to maintain allocations. If you free/delete after a heap overflow on modern clib you're likely to get a segfault.
Canary Conundrums - Oh no! The target is on the other side of a canary from the vulnerable buffer! When function a returns there's bound to be a segfault. If function a returns...
Integer Behavior - Hmm, it looks like there's some careful sanitization on that integer input. How does that ALU thing work again? Plus, this was compiled with AddressSanitizer. One wrong byte and it'll be a segfault.
Heap Havoc - In the real world the heap is constantly changing. Challenge number 2 is pretty trivial compared to this one.
AddressSanitizer Woes - AddressSanitizer is extremely carefully thought out. It was very challenging to balance improved security without breaking backwards compatibility. Sometimes, all it takes is a few corrupted bytes to pop a shell. That's good, because AddressSanitizer doesn't give you all that many bytes to work with.
More to come later...