[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJ_zFkLHRZdy0K2EaBny7btAj_-5vHiUxD4zSyLUqVyt86x+Wg@mail.gmail.com>
Date: Tue, 26 May 2015 12:53:04 -0700
From: Tavis Ormandy <taviso@...gle.com>
To: oss-security@...ts.openwall.com
Subject: Re: Re: hwclock(8) SUID privilege escalation
On Tue, May 26, 2015 at 6:59 AM, Stephane Chazelas
<stephane.chazelas@...il.com> wrote:
> 2015-05-26 12:47:47 +0200, up201407890@...nos.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.
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.
