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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ