Re: Why SUID Binary exploit does not yield root shell?

[Andres Roldan <aroldan () fluidsignal com>]

Brian Hatch <vuln-dev () ifokr org> writes:

> > I've managed to find a buffer overflow and exploit it to exeve a /bin/sh 
> > using my payload shellcode. However, whenever I run my exploit, I do get a 
> > shell but just that it is an ordinary shell under my account (as id would 
> > indicate).
>
> Some /bin/sh's will drop privs if uid != euid.  Bash is one of these.

That's true, but in this case he also tried with another buggy suid binary 
(at least that's what he said) and it _did_ work. If it were a bash protection 
technique, none of the buggy binaries could have given a root shell.

> Instead of using /bin/sh during your test, try /usr/bin/id just to
> see what uid and euid are.  If euid is root yet /bin/sh is not yielding
> root, that's the cause.  You can always compile your own sh frontend
> to fix uid too:
>
> ...
> main () {
>       setuid(0); seteuid(0); setgid(0);
>       execve("/bin/sh",...)
> }

That is actually the only way I know to get a root bash prompt with the last bash versions 

> Compile, install, and call that instead.  You should probably just
> include setuid(0) instructions into your shellcode to avoid the
> middle man.  Or you could call /bin/csh which usually doesn't drop
> privs (but leaves folks stuck in the unpleasant world of C shell)

csh isn't actually an unpleasant shell :)

> or any pretty much other shell-like program.
>
> > What is the magic here (if any)?
>
> Bash is being "smarter" than you want it to be.
>
> --
> Brian Hatch                  Is a book on
>    Systems and                voyeurism a
>    Security Engineer          peeping tome.
> http://www.ifokr.org/bri/
>
> Every message PGP signed

-- 
Andres Roldan 
CSO, Fluidsignal Group S.A.