> 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.
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",...)
}
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)
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
This archive was generated by hypermail 2b30 : Sun Mar 09 2003 - 13:42:14 PST