oss-sec mailing list archives
Re: local privilege escalation due to capng_lock as used in seunshare
From: Steve Grubb <sgrubb () redhat com>
Date: Tue, 29 Apr 2014 18:18:58 -0400
On Wednesday, April 30, 2014 02:12:22 AM Solar Designer wrote:
On Tue, Apr 29, 2014 at 05:49:04PM -0400, Steve Grubb wrote:On Tuesday, April 29, 2014 02:20:47 PM Andy Lutomirski wrote:if (setuid(getuid()) != 0) err(1, "setuid(getuid())");If you do not want the saved uid to be available, you need to use setresuid. That removes it. I would classify this as a bug in the test program.Not quite.
If the program was amended to use setresuid(), does the bug still exist? -Steve
Per POSIX.1-2001, setuid() "shall set the real user ID, effective user ID, and the saved set-user-ID of the calling process to uid" if the process has "appropriate privileges". On traditional Unix systems, without capabilities, running as root historically does constitute "appropriate privileges". If we want current systems to support safely running programs written for traditional Unix (including SUID root programs), which I think is taken for granted by many of us, we must not deviate from those semantics in dangerous ways. Any such deviation is a vulnerability in our current kernel code or configuration. Distributions must not ship with settings or programs that allow anyone other than an administrator to alter the definition of "appropriate privileges" in a way that, while compliant with this vague wording in POSIX, introduces a vulnerability for correct programs written for traditional Unix systems. What we have here is a reincarnation of: "Sendmail Workaround for Linux Capabilities Bug" https://www.sendmail.com/sm/open_source/security/security_docs/sendmail.8.10 .1.LINUX-SECURITY.txt albeit in slightly different shape (not entirely in the kernel, but with a userland "helper"). I think that sendmail-exposed vulnerability was in the kernel (not in sendmail), and I think the vulnerability Andy is reporting is in some distros (apparently, Red Hat's). Of course, it is possible that I have missed something important as I did not look into this issue closely, but the above is my current understanding based on Andy's message. Alexander
Current thread:
- local privilege escalation due to capng_lock as used in seunshare Andy Lutomirski (Apr 29)
- Re: local privilege escalation due to capng_lock as used in seunshare Steve Grubb (Apr 29)
- Re: local privilege escalation due to capng_lock as used in seunshare Solar Designer (Apr 29)
- Re: local privilege escalation due to capng_lock as used in seunshare Steve Grubb (Apr 29)
- Re: local privilege escalation due to capng_lock as used in seunshare Solar Designer (Apr 29)
- Re: local privilege escalation due to capng_lock as used in seunshare Steve Grubb (Apr 30)
- Re: local privilege escalation due to capng_lock as used in seunshare Andy Lutomirski (Apr 30)
- Re: Re: local privilege escalation due to capng_lock as used in seunshare Steve Grubb (Apr 30)
- Re: local privilege escalation due to capng_lock as used in seunshare Solar Designer (Apr 30)
- Re: local privilege escalation due to capng_lock as used in seunshare Solar Designer (Apr 30)
- Re: local privilege escalation due to capng_lock as used in seunshare Andy Lutomirski (Apr 30)
- Re: local privilege escalation due to capng_lock as used in seunshare Daniel J Walsh (May 01)
- Re: local privilege escalation due to capng_lock as used in seunshare Solar Designer (Apr 29)
- Re: local privilege escalation due to capng_lock as used in seunshare Steve Grubb (Apr 29)
- Re: local privilege escalation due to capng_lock as used in seunshare Solar Designer (Apr 30)
- Re: local privilege escalation due to capng_lock as used in seunshare John Haxby (Apr 30)