[SOLVED] suid bit on executable wont spawn a shell

jazzmo · 08-12-2011, 06:27 AM

Hi,

I've trying to understand the concept of buffer overflows and I tried to understand how the shellcode is executed. To start simple I've created the following program

Code:

// shell.c 
int main(){ 
  char *name[2]; 

  name[0] = "/bin/sh"; 
  name[1] = 0x0; 
  execve(name[0], name, 0x0); 
  exit(0); 
}

now when i compile this code and

Code:

# chown root:root shell 
# chmod 4755 shell
# ls -ahl
# -rwsr-sr-x  1 root   root  8.0K Aug 11 17:08 shell

I would expect when I run this as a regular user I get a root shell. What happens is that a shell with my user is spawned. On the other hand when I compile this code

Code:

//suidshell.c 
#include <sys/types.h> 
#include <unistd.h> 
#include <stdio.h> 

int main(void) { 
    printf( 
        "Real      UID = %d\n" 
        "Effective UID = %d\n" 
        "Real      GID = %d\n" 
        "Effective GID = %d\n", 
        getuid (), 
        geteuid(), 
        getgid (), 
        getegid() 
    ); 
    return 0; 
}

compile it, and set the owner and permissions as in the example above i get as output

Code:

Real UID = 1001 
Effective UID = 0 
Real GID = 100 
Effective GID = 100

so it looks like there is some mechanism (in the kernel?) which prevents a suid program from executing a root shell. Is there any way to "switch" this off? I've learned for example that ASLR can be switched off with

Code:

#  sysctl -w kernel.randomize_va_space=0

thanks for the answers,
and kind regards

Noway2 · 08-12-2011, 08:06 AM

Quote:

so it looks like there is some mechanism (in the kernel?) which prevents a suid program from executing a root shell.

Yes, there is. I was looking into this a few months back and ran into similar "problems" and discovered that there are more security mechanism built into setuid than just setting the bit and changing the ownership to root. I apologize, but it has been too long since I worked on it to recall the exact details, but if you do a google search for setuid tutorials you should find the references which will show you how to make it work.

orgcandman · 08-12-2011, 09:38 AM

/bin/sh is typically a link to /bin/bash. For a while now, bash will always switch to real user-id. If you add a call in your shell example:

Code:

 setuid(0);

You should find that it works as expected. NOTE: this is because of how setuid behaves when euid = 0. As a confirmation, change the setuid sticky bit on your bash shell and watch what happens :P

One additional thing to note is that this helps to enforce the mindset of "don't use setuid scripts." There are many reasons why we want to avoid them, not the least of which is because people can find TONS of ways to inject execution into your setuid script without you even knowing it.

-Aaron

jazzmo · 08-23-2011, 09:36 AM

Hi,

I finally found the answer to the question:

i downloaded the bash source and grepped geteuid

Code:

grep -r getuid bash-3.01

two hits were found. One in ./shell.c another in ./lib/intl/dcigettext.c
after replacing the occurences with geteuid it just worked fine.

Thanks for helping.

Noway2 · 08-23-2011, 07:13 PM

Jazzmo, would you please elaborate on your approach. I don't mean to offend, but modifying the bash source code without performing some serious regression testing might be a really good way to open up some vulnerabilities.

I might also suggest that you take a look at this link: http://www.tuxation.com/setuid-on-shell-scripts.html
I am reasonably certain that it is the one that I used when I was experimenting with setuid and had the same problem that I think you are running into.

jazzmo · 08-24-2011, 01:14 AM

Quote:

Originally Posted by Noway2

Jazzmo, would you please elaborate on your approach. I don't mean to offend, but modifying the bash source code without performing some serious regression testing might be a really good way to open up some vulnerabilities.

I might also suggest that you take a look at this link: http://www.tuxation.com/setuid-on-shell-scripts.html
I am reasonably certain that it is the one that I used when I was experimenting with setuid and had the same problem that I think you are running into.

Hi Noway2,

as I wrote in the beginning, i'm experimenting with buffer overflows. Mostly they spawn a shell. I didn't understand how someone would get a root shell by exploiting a setuid executable. Now I understand that the shell itself prevents this, so the shellcode must do something different. If the process is run by root the exploit would result in a root shell. Of course I wouldn't weaken the security of my productive systems this way, although I also learned that this could be a simple backdoor too.

cheers

rodrifra · 08-25-2011, 03:42 AM

If you want to experiment and learn, try http://roothack.org/games/sirens/info first server is too simple, just privilege scalation. Sencond server is the interesting one, there you have to do buffer overflows, use string vulnerabilities and so on. I learnt a lot there.

jazzmo · 08-25-2011, 06:21 AM

On more note on this. Since /bin/dash isn't checking the uid it WILL spawn a root shell, so compared to bash it is less secure in my opinion.