1

I've been working on the exploit-exercises.com "protostar" distro. I'm currently baffled, as I'm getting a really weird error working on stack5.

I have verified that I successfully transfer control to my shellcode by using '\xcc' (SIGTRAP) opcodes at the beginning of my shellcode and testing it in GDB (I have now removed them).

To make it as simple as possible, the goal of my shellcode is to get the program to exit with a status of 1.

When I run it in GDB, it successfully triggers the exploit and exits with a code of 1. Yay!

...

But for some reason, when I quit GDB and try to run it in the shell, It gives me an 'Illegal instruction' interrupt and exits with a code of 132.

The shellcode that I'm using is: http://repo.shell-storm.org/shellcode/files/shellcode-470.php with the minor adjustment of zeroing out %eax and %ebx at the beginning to ensure that they are the proper value for the 0x80 syscall.

The command that I'm using to create my exploit file is:

perl -e 'print "A"x76 . "\x3a\xfd\xff\xbf" . "\x90"x20 . "\x33\xdb\x33\xc0\x40\x43\xcd\x80"' > stack5_exploit

Does anyone have an idea as to why running it inside GDB would result in different output?

I'm guessing it might have something to do with how the 0x80 interrupt is handled, but I have much more experience with Windows internals than Linux.

grg
  • 5,023
  • 3
  • 34
  • 50
Tom Cornelius
  • 131
  • 4

2 Answers2

1

Nevermind, I figured it out.

the environment variables are different in a gdb-execution than they are during the normal execution of the program.

One notable difference is apparent in the imgur link: in gdb, the program is being invoked using its full path (/opt/protostar/bin/stack5) while outside the debugger, it is being invoked using its relative path (./stack5).

As argv[0] holds the string of the program as it was invoked; moving my payload up the stack and causing me to miss my '\x90' sled.

Additionally, gdb sets the environment variables LINES and COLUMNS, which can be nullified to get 'real' addresses while debugging.

Thanks matthias!

Link to comment: Buffer overflow works in gdb but not without it

Community
  • 1
  • 1
Tom Cornelius
  • 131
  • 4
0

I have not looked in detail at your test, but one thing to note is that GDB disables address space randomization by default. Usually that's what you want while debugging, so that variable addresses stay fixed from run to run.

My guess is that your exploit doesn't work when ASLR is on.

You can ask GDB to enable address randomization with set disable-randomization off command.

You can also run your program outside GDB with ASLR disabled:

setarch -R i386 stack5 < stack5_exploit
Employed Russian
  • 199,314
  • 34
  • 295
  • 362