Brian Hatch <vuln-devat_private> 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.
This archive was generated by hypermail 2b30 : Mon Mar 10 2003 - 14:36:18 PST