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.