[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1490736.DoQLuBMoN2@x2>
Date: Wed, 30 Apr 2014 21:27:10 -0400
From: Steve Grubb <sgrubb@...hat.com>
To: oss-security@...ts.openwall.com
Cc: Andy Lutomirski <luto@...capital.net>, solar@...nwall.com
Subject: Re: Re: local privilege escalation due to capng_lock as used in seunshare
On Wednesday, April 30, 2014 04:07:19 PM Andy Lutomirski wrote:
> On 04/30/2014 08:55 AM, Steve Grubb wrote:
> > On Wednesday, April 30, 2014 02:35:52 AM Solar Designer wrote:
> >> On Tue, Apr 29, 2014 at 06:18:58PM -0400, Steve Grubb wrote:
> >>> 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?
> >>
> >> Yes, because it affects other similar correct programs that haven't yet
> >> been amended to work safely on your non-Unix system. ;-) Alternatively,
> >> you may declare that your system is deliberately incapable of running
> >> programs written for traditional Unix safely, and will stay that way.
> >> That will be a reason for people to prefer other Linux distros over Red
> >> Hat's, but at least it'd be fair. ;-(
> >>
> >> To paraphrase your question, since sendmail got a workaround for the old
> >> capabilities bug in the Linux kernel, does the bug in those old kernel
> >> versions still exist? The answer is also yes, it does, potentially
> >> affecting other programs running on those vulnerable kernels.(*) The
> >> bug needed to be fixed in the kernel, and it was (for later versions).
> >>
> >> (*) Of course, most people should not actually run those old kernels
> >> because of other vulnerabilities that have been found and fixed since,
> >> but that's a separate matter.
> >>
> >> I hope you don't mind the rhetoric. I mean it to be friendly. I hope
> >> it serves to deliver the message well.
> >
> > No problem. I chatted with Petr Matousek about this and I think we
> > understand the issue now.
> >
> > In my opinion, the issue is that I think SECURE_NOROOT doesn't get its
> > semantics right as is. I'm thinking if noroot is set and cap_setuid is
> > set, suid should be as normal but with no capabilities. If noroot is set
> > and cap_setuid is unset, no transition of any uid should occur. If noroot
> > is unset, then works as normal.
> >
> > If this was not the intention, then SECURE_NOSUID should have been created
> > at the same time the other SECUREBITS options were created so that each
> > part of credential change could be completely controlled. Not designing
> > the ability to control all parts is what creates this hole...for years I
> > might add.
> >
> > So, I wonder if SECURE_NOROOT should be fixed or if ancient kernels need
> > to suddenly backport PR_SET_NO_NEW_PRIVS?
>
> I suspect that fixing SECURE_NOROOT will be basically impossible. I'm
> not sure that anyone knows what it's supposed to do, and there is an
> amazing amount of inertia preventing any changes to Linux's capability
> system.
>
> I'd support an effort to kill securebits, but that might also be impossible.
>
> Backporting PR_SET_NO_NEW_PRIVS would be easy, but I don't know how many
> people are still supporting kernels that don't have it. IIRC it was
> added in Linux 3.5. I guess RHEL5 and RHEL6 could be candidates. TBH
> it might actually be safer to turn off securebits entirely in capng_lock
> -- I suspect that the class of attacks enabled by setting securebits is
> larger than the class that is mitigated.
>
> For distros that are affected (SUSE/OpenSUSE?), the latest upstream
> cap-ng is now patched to use PR_SET_NO_NEW_PRIVS.
And switching to NO_NEW_PRIVS broke the sandbox:
https://bugzilla.redhat.com/show_bug.cgi?id=1091761
So, perhaps fixing SECURE_NOROOT is the safest bet? Are there any other
opinions on this?
-Steve
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.
