I am currently trying to perform a return-to-libc attack against a locally run program. Here are the steps I did:
I calculated the bytes needed to overwrite the saved return address
I used a buffer overflow to overwrite the saved return address with the address of a "pop rdi ; ret" gadget so that I can call system() with the string "/bin/sh" as an argument (the program is 64 bit)
After the overwritten return address I put the address of the string "/bin/sh", so that the "pop rdi" instruction would pop the address of "/bin/sh" into the rdi register
After that I put the address of the system function in libc (ASLR is off, so the address is static)
To summarize, the stack looks like this:
padding|address_of_pop_rdi|address_of_binsh|address_of_system_in_libc
All of the addresses are converted using the p64() method of python lib pwntools
Whenever I run the exploit, the program crashes with a SIGSEGV (segmentation fault), which leads me to believe that the padding length is incorrect, but here is the weird thing:
When I step through the exploit using GDB, I can see that the saved rip is set correctly to the address of the pop_rdi gadget. When I step further I can see, that the address of "/bin/sh" is popped correctly into the RDI register. When I step even further, I can see the system function being executed. No matter how many times I step further, the program never crashes with a SIGSEGV. Execution just stops at some point, which I think is because the program is waiting for a shell command to be entered.
Has anyone else run into this porblem? Is there maybe some protection enabled which automatically terminates the program because an exploit is detected? The binary has no canaries, no PIE but runs NX.
I appreciate any help I can get, because I am dead lost
I can provide screenshots if needed
Thanks in advance!
