Re: local privilege escalation due to capng_lock as used in seunshare

[Andy Lutomirski <luto () amacapital net>]

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.

--Andy