Buffer Overflows on Modern Systems?

Hello Everyone,

Recently I have been going back to some of the protostar challenges and trying to execute them on a modern system. I obviously didn’t expected the traditional exploitation methods to work. Nonetheless I was surprised that I couldn’t even overwrite the return address:

(strace -i output)

My System → [000055808bd0a6d6] — SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} —

Protostar Image → [414141414141] — SIGSEGV (Segmentation fault) @ 0 (0)

From what I have read it appears that anti-exploitation techniques copy “the return address of a function to a safe place (usually to the start of the data segment) at the start of the function. When the function terminates, it compares the two function return address, the one in the stack and the one stored in data segment. In the case of a mismatch, the function aborts immediately”. My question(s) is whether this is what is preventing me from overwriting the return address and whether I can temporarily disable this behavior.
Thanks

n3m0

Protostar Challenges: Homepage One - exploit-exercises.com

Your system is probably 64 bit. As by specifications, on 64 bit the maximum address space allowed in hardware is 48 bits. Think like “you only have 48 hardware lines”. Therefore, all addresses are at most 6 bytes long and have to start with 0x00 0x00 (example: 0x00007ffeaa002244). This means that if you overwrite RIP with 'a’s you get: 0x4141414141414141, which is an invalid address. The OS traps this illegal attempt and dies at the ‘ret’ instruction (you may check this easily with gdb).
Wait, it’s even worse: in 64 bit OSes, the stack layout isn’t handled exactly the same as in 32 bit. The innermost function doesn’t get stack allocated for performance reasons; instead, it uses a 128 byte byte called “red zone” that is prepared by GCC at compile time. Therefore, RSP doesn’t grow down during the innermost call; it stays the same as RBP.
Hope this helps. Read here for more:

Hello @davidlightman,
I just looked at the link and you are absolutely right! Thank you so much for this insight. I never knew about this and was pretty surprised. I was going nuts looking at the dmesg and strace outputs :slight_smile:
Thank You

n3m0