[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5983384.fqBtkCuopK@x2>
Date: Wed, 30 Apr 2014 11:55:31 -0400
From: Steve Grubb <sgrubb@...hat.com>
To: Solar Designer <solar@...nwall.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: local privilege escalation due to capng_lock as used in seunshare
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?
-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.
