Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 26 May 2015 12:53:04 -0700
From: Tavis Ormandy <>
Subject: Re: Re: hwclock(8) SUID privilege escalation

On Tue, May 26, 2015 at 6:59 AM, Stephane Chazelas
<> wrote:
> 2015-05-26 12:47:47 +0200,
> [...]
>> 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


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.