Re: Re: hwclock(8) SUID privilege escalation

[Tavis Ormandy <taviso () google com>]

On Tue, May 26, 2015 at 6:59 AM, Stephane Chazelas
<stephane.chazelas () gmail com> wrote:
> 2015-05-26 12:47:47 +0200, up201407890 () alunos dcc fc up pt:
> [...]
> > Please note that this is possible on Debian-derived (and therefore Ubuntu),
> > because /bin/sh is provided by dash which does NOT make use
> > of privmode (does not drop privileges if ruid != euid, unlike bash),
> > which is a very stupid idea.
> >
> > privmode is surprisingly effective at mitigating some common vulnerability
> > classes and misconfigurations, and it has been around since mid 90's.
> > Indeed, Chet Ramey (bash author and maintainer) explains that the
> > purpose of this is to prevent "bogus system(3)/popen(3) calls in
> > setuid executables"
> [...]
>
> No, bash does NOT drop privileges if ruid != euid when called as
> sh either . If it were, it would break those commands that use
> system()/popen() from suid/sgid executables (which arguably they
> shouldn't be doing) and expect the euid/egid to be preserved.

Yes it does, you are most likely a Debian user. Debian patched bash to
add the behavior you describe back because someone complained it broke
uucp delivery in 1999 (see debian bug 52586).

That is why popen() in setuid programs are usually only exploitable on
Debian/Ubuntu, see this link for more discussion
http://www.openwall.com/lists/oss-security/2013/08/22/12

Tavis.