8

I am trying to exploit a SUID program.

The program is:

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


#define e(); if(((unsigned int)ptr & 0xff000000)==0xca000000) { setresuid(geteuid(), geteuid(), geteuid()); execlp("/bin/sh", "sh", "-i", NULL); }

void print(unsigned char *buf, int len)
{
int i;
printf("[ ");
for(i=0; i < len; i++) printf("%x ", buf[i]); 
printf(" ]\n");
}

int main()
{
unsigned char buf[512];
unsigned char *ptr = buf + (sizeof(buf)/2);
unsigned int x;

while((x = getchar()) != EOF) {
        switch(x) {
                case '\n': 
                      print(buf, sizeof(buf)); continue; break;
                case '\\': 
                      ptr--; break; 
                default: 
                      e(); 

                      if(ptr > buf + sizeof(buf)) 
                            continue; 

                      ptr++[0] = x; break;
        }
}
printf("All done\n");
}

We can easily see that if we somehow change ptr's contents to some address that starts with CA then a new shell will be spawned for us. And as ptr normally holds some address starting with FF the way to decrease it(ptr) is to enter \ character. So I make a file with 0x35000000 '\' characters, and finally 3 'a' at the end of the file

perl -e "print '\\\'x889192448" > file     # decimal equivalent of 0x35000000
echo aaa >> file        # So that e() is called which actually spawns the shell

And finally in gdb,

run < file

However instead of spawning a shell gdb is saying

process <some number> is executing new program /bin/dash
inferior 1 exited normally

And then back to gdb prompt instead of getting a shell. I have confirmed by setting breakpoints at appropriate locations that ptr is indeed starting with CA before setresuid() gets called.

Also if I pipe this outside of gdb, nothing happens.

./vulnProg < file

Bash prompt returns back.

Please tell me where am I making mistake.

4
  • 1
    I've had much better luck getting exploit code to run outside of GDB. I would focus on getting the program to run and to be exploited outside of GDB. Focus on why that is not working.
    – Chris Dale
    Commented Jun 22, 2015 at 8:22
  • 1
    I agree with @ChrisDale. Debuggers can change the way programs can be vulnerable. Attempt to fix without GDB attached because chances are GDB is not your main issue..
    – RoraΖ
    Commented Jun 22, 2015 at 11:13
  • Thanks for your responses, but I would really very much appreciate some more light, because I am totally frustrated. Commented Jun 22, 2015 at 11:21
  • Gdb may be detecting the pointer change as a bug and is trying to help you debug it. Try without dbg and post symptoms Commented Jun 22, 2015 at 16:43

1 Answer 1

3

This may be a little late but GDB stays attached to the parent process when a program forks by default. To make GDB follow the forking process add set follow-fork-mode child to your .gdbinit. GDB will then follow the shell process that is spawned when your exploit lands. More information about gdb and forking processes is available at https://sourceware.org/gdb/onlinedocs/gdb/Forks.html.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .