* Re: 2015 kernel CVEs
2016-01-19 11:28 ` 2015 kernel CVEs Dan Carpenter
@ 2016-01-19 14:56 ` One Thousand Gnomes
2016-01-19 16:32 ` [kernel-hardening] " Ben Hutchings
` (6 subsequent siblings)
7 siblings, 0 replies; 20+ messages in thread
From: One Thousand Gnomes @ 2016-01-19 14:56 UTC (permalink / raw)
To: Dan Carpenter; +Cc: linux-kernel, kernel-hardening
On Tue, 19 Jan 2016 14:28:12 +0300
Dan Carpenter <dan.carpenter@oracle.com> wrote:
> I like to look back over old CVEs to see how we could do better. Here
> is the list from 2015. I got most of this information from the Ubuntu
> CVE tracker. Thanks Ubuntu!. If it doesn't have a hash that means it
> might not be fixed yet.
That's the list of bugs originating in 2015. You need to go back further
to see some of the fun ones still present (CVE-2013-7445 for example)
> There was only a coupls CVEs that looks like they came from a filesystem
> fuzzer where you create a corrupt filesystems and then try use them.
> There was only one that might have come from a USB fuzzer. We probably
> should be testing those things better.
There are a bunch of those ignored in Bugzilla for years. I think the
ones for the mainstream file systems have all been tackled but things
like reiserfs don't survive fuzzing too well, which is a problem if your
distribution naïvely builds in automounting support for people rooting
your box via USB stick.
Alan
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [kernel-hardening] 2015 kernel CVEs
2016-01-19 11:28 ` 2015 kernel CVEs Dan Carpenter
2016-01-19 14:56 ` One Thousand Gnomes
@ 2016-01-19 16:32 ` Ben Hutchings
2016-01-19 17:54 ` Greg KH
2016-01-19 16:57 ` Peter Hurley
` (5 subsequent siblings)
7 siblings, 1 reply; 20+ messages in thread
From: Ben Hutchings @ 2016-01-19 16:32 UTC (permalink / raw)
To: kernel-hardening, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2358 bytes --]
On Tue, 2016-01-19 at 14:28 +0300, Dan Carpenter wrote:
> I like to look back over old CVEs to see how we could do better. Here
> is the list from 2015. I got most of this information from the Ubuntu
> CVE tracker. Thanks Ubuntu!. If it doesn't have a hash that means it
> might not be fixed yet.
[...]
> CVE-2013-2015 0e9a9a1ad619: ext4: hang during mount
[...]
That's not *from* 2015.
You missed a few recent ones:
CVE-2015-7566 : Crash on invalid USB device descriptors in visor driver
CVE-2015-8550 54d5d882c7e4, 0f589967a73f, 68a33bfd8403, 1f13d75ccb80, 18779149101c, be69746ec12f, 8135cf8b0927: paravirtualized drivers incautious about shared memory contents
CVE-2015-8551 56441f3c8e5b, 5e0ce1455c09, a396f3a210c3, 7cfb905b9638, 408fb0e5aa7f: Linux pciback missing sanity checks leading to crash
CVE-2015-8552 56441f3c8e5b, 5e0ce1455c09, a396f3a210c3, 7cfb905b9638, 408fb0e5aa7f: Linux pciback missing sanity checks leading to crash
(There's some subtle distinction between the last two.)
[...]
> There was only a coupls CVEs that looks like they came from a filesystem
> fuzzer where you create a corrupt filesystems and then try use them.
> There was only one that might have come from a USB fuzzer. We probably
> should be testing those things better.
I think that hardening filesystems is a losing battle. We can fuzz
with and protect against invalid static filesystem images, but the full
problem includes malicious removable storage devices that can exploit
TOCTTOU issues. We should probably be encouraging distributions to
mount removable devices using FUSE and to run the filesystem code with
minimal privileges.
As for USB descriptors, I'm somewhat more hopeful about hardening. At
the same time, it seems like it should be practical to put more low-
performance USB drivers into userspace.
[...]
> A lot of the bugs are just really complicated things with funny corner
> cases, namespace issues or people just made mistake in the logic and
> it's hard to do anything about it.
We can add chicken bits so that admins who don't need certain features
can turn them off (or, inversely, those who do need them will need to
turn them on).
Ben.
--
Ben Hutchings
Horngren's Observation:
Among economists, the real world is often a special case.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [kernel-hardening] 2015 kernel CVEs
2016-01-19 16:32 ` [kernel-hardening] " Ben Hutchings
@ 2016-01-19 17:54 ` Greg KH
2016-01-20 17:05 ` Ben Hutchings
0 siblings, 1 reply; 20+ messages in thread
From: Greg KH @ 2016-01-19 17:54 UTC (permalink / raw)
To: kernel-hardening; +Cc: linux-kernel
On Tue, Jan 19, 2016 at 04:32:08PM +0000, Ben Hutchings wrote:
> As for USB descriptors, I'm somewhat more hopeful about hardening. At
> the same time, it seems like it should be practical to put more low-
> performance USB drivers into userspace.
What drivers do we currently have in the kernel that should/could be
done in userspace instead? I'll gladly drop them from the tree.
And yes, we need to do better about handling crazy USB descriptors, I
think the majority of this work is already done, but it takes
hand-auditing to verify it :(
thanks,
greg k-h
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [kernel-hardening] 2015 kernel CVEs
2016-01-19 17:54 ` Greg KH
@ 2016-01-20 17:05 ` Ben Hutchings
2016-01-20 18:04 ` Greg KH
0 siblings, 1 reply; 20+ messages in thread
From: Ben Hutchings @ 2016-01-20 17:05 UTC (permalink / raw)
To: kernel-hardening; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
On Tue, 2016-01-19 at 09:54 -0800, Greg KH wrote:
> On Tue, Jan 19, 2016 at 04:32:08PM +0000, Ben Hutchings wrote:
> > As for USB descriptors, I'm somewhat more hopeful about hardening. At
> > the same time, it seems like it should be practical to put more low-
> > performance USB drivers into userspace.
>
> What drivers do we currently have in the kernel that should/could be
> done in userspace instead? I'll gladly drop them from the tree.
An obvious example would be HID drivers. (I'll grant you that putting
those in user-space would complicate the boot process when a disk
encryption passphrase is needed.)
Ben.
> And yes, we need to do better about handling crazy USB descriptors, I
> think the majority of this work is already done, but it takes
> hand-auditing to verify it :(
--
Ben Hutchings
The program is absolutely right; therefore, the computer must be wrong.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [kernel-hardening] 2015 kernel CVEs
2016-01-20 17:05 ` Ben Hutchings
@ 2016-01-20 18:04 ` Greg KH
2016-01-21 15:18 ` Jiri Kosina
2016-01-21 18:46 ` Ben Hutchings
0 siblings, 2 replies; 20+ messages in thread
From: Greg KH @ 2016-01-20 18:04 UTC (permalink / raw)
To: kernel-hardening; +Cc: linux-kernel
On Wed, Jan 20, 2016 at 05:05:39PM +0000, Ben Hutchings wrote:
> On Tue, 2016-01-19 at 09:54 -0800, Greg KH wrote:
> > On Tue, Jan 19, 2016 at 04:32:08PM +0000, Ben Hutchings wrote:
> > > As for USB descriptors, I'm somewhat more hopeful about hardening. At
> > > the same time, it seems like it should be practical to put more low-
> > > performance USB drivers into userspace.
> >
> > What drivers do we currently have in the kernel that should/could be
> > done in userspace instead? I'll gladly drop them from the tree.
>
> An obvious example would be HID drivers. (I'll grant you that putting
> those in user-space would complicate the boot process when a disk
> encryption passphrase is needed.)
That and for userspace that expects to get an input device stream,
combining serial, ps2, bluetooth, and USB devices all at the same time.
So while it might be possible, keeping input devices and HID support in
the kernel makes sense.
Except for those drivers that abuse the HID interface due to the
decisions the Windows developers made years ago, and are not reall HID
devices, those should all be done in userspace, just like Windows does.
Hopefully we have been good in keeping those types of drivers out of the
kernel.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [kernel-hardening] 2015 kernel CVEs
2016-01-20 18:04 ` Greg KH
@ 2016-01-21 15:18 ` Jiri Kosina
2016-01-21 18:46 ` Ben Hutchings
1 sibling, 0 replies; 20+ messages in thread
From: Jiri Kosina @ 2016-01-21 15:18 UTC (permalink / raw)
To: Greg KH; +Cc: kernel-hardening, linux-kernel
On Wed, 20 Jan 2016, Greg KH wrote:
> Except for those drivers that abuse the HID interface due to the
> decisions the Windows developers made years ago, and are not reall HID
> devices, those should all be done in userspace, just like Windows does.
> Hopefully we have been good in keeping those types of drivers out of the
> kernel.
This has been one of the motivations for creating hidraw interface. So my
hope here is that we're doing reasonably well in this respect.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [kernel-hardening] 2015 kernel CVEs
2016-01-20 18:04 ` Greg KH
2016-01-21 15:18 ` Jiri Kosina
@ 2016-01-21 18:46 ` Ben Hutchings
1 sibling, 0 replies; 20+ messages in thread
From: Ben Hutchings @ 2016-01-21 18:46 UTC (permalink / raw)
To: kernel-hardening; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]
On Wed, 2016-01-20 at 10:04 -0800, Greg KH wrote:
> On Wed, Jan 20, 2016 at 05:05:39PM +0000, Ben Hutchings wrote:
> > On Tue, 2016-01-19 at 09:54 -0800, Greg KH wrote:
> > > On Tue, Jan 19, 2016 at 04:32:08PM +0000, Ben Hutchings wrote:
> > > > As for USB descriptors, I'm somewhat more hopeful about hardening. At
> > > > the same time, it seems like it should be practical to put more low-
> > > > performance USB drivers into userspace.
> > >
> > > What drivers do we currently have in the kernel that should/could be
> > > done in userspace instead? I'll gladly drop them from the tree.
> >
> > An obvious example would be HID drivers. (I'll grant you that putting
> > those in user-space would complicate the boot process when a disk
> > encryption passphrase is needed.)
>
> That and for userspace that expects to get an input device stream,
> combining serial, ps2, bluetooth, and USB devices all at the same time.
> So while it might be possible, keeping input devices and HID support in
> the kernel makes sense.
[...]
I was thinking that the HID drivers would feed events back into the
kernel through an enhanced version of evdev_write(). The userland
consumers of input events wouldn't need to change at all.
Ben.
--
Ben Hutchings
Horngren's Observation:
Among economists, the real world is often a special case.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2015 kernel CVEs
2016-01-19 11:28 ` 2015 kernel CVEs Dan Carpenter
2016-01-19 14:56 ` One Thousand Gnomes
2016-01-19 16:32 ` [kernel-hardening] " Ben Hutchings
@ 2016-01-19 16:57 ` Peter Hurley
2016-01-19 17:00 ` Josh Boyer
2016-01-19 17:57 ` [kernel-hardening] " Theodore Ts'o
` (4 subsequent siblings)
7 siblings, 1 reply; 20+ messages in thread
From: Peter Hurley @ 2016-01-19 16:57 UTC (permalink / raw)
To: Dan Carpenter, linux-kernel; +Cc: kernel-hardening, Greg KH
On 01/19/2016 03:28 AM, Dan Carpenter wrote:
> I like to look back over old CVEs to see how we could do better. Here
> is the list from 2015. I got most of this information from the Ubuntu
> CVE tracker. Thanks Ubuntu!. If it doesn't have a hash that means it
> might not be fixed yet.
[...]
> CVE-2015-4170 cf872776fc84: tty: hang in tty
Makes no sense that this was assigned a CVE.
I fixed this _2 yrs before_ it was reported and the patch was CC'd stable.
Regards,
Peter Hurley
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: 2015 kernel CVEs
2016-01-19 16:57 ` Peter Hurley
@ 2016-01-19 17:00 ` Josh Boyer
2016-01-19 17:51 ` Greg KH
0 siblings, 1 reply; 20+ messages in thread
From: Josh Boyer @ 2016-01-19 17:00 UTC (permalink / raw)
To: Peter Hurley
Cc: Dan Carpenter, Linux-Kernel@Vger. Kernel. Org, kernel-hardening,
Greg KH
On Tue, Jan 19, 2016 at 11:57 AM, Peter Hurley <peter@hurleysoftware.com> wrote:
> On 01/19/2016 03:28 AM, Dan Carpenter wrote:
>> I like to look back over old CVEs to see how we could do better. Here
>> is the list from 2015. I got most of this information from the Ubuntu
>> CVE tracker. Thanks Ubuntu!. If it doesn't have a hash that means it
>> might not be fixed yet.
>
> [...]
>
>> CVE-2015-4170 cf872776fc84: tty: hang in tty
>
> Makes no sense that this was assigned a CVE.
> I fixed this _2 yrs before_ it was reported and the patch was CC'd stable.
I'm guessing the CVE was assigned because there are distributions that
ship based on kernels earlier than 3.13. Those distributors need to
verify if they have the fix, etc.
josh
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 2015 kernel CVEs
2016-01-19 17:00 ` Josh Boyer
@ 2016-01-19 17:51 ` Greg KH
2016-01-20 7:12 ` [kernel-hardening] " Marcus Meissner
0 siblings, 1 reply; 20+ messages in thread
From: Greg KH @ 2016-01-19 17:51 UTC (permalink / raw)
To: Josh Boyer
Cc: Peter Hurley, Dan Carpenter, Linux-Kernel@Vger. Kernel. Org,
kernel-hardening
On Tue, Jan 19, 2016 at 12:00:57PM -0500, Josh Boyer wrote:
> On Tue, Jan 19, 2016 at 11:57 AM, Peter Hurley <peter@hurleysoftware.com> wrote:
> > On 01/19/2016 03:28 AM, Dan Carpenter wrote:
> >> I like to look back over old CVEs to see how we could do better. Here
> >> is the list from 2015. I got most of this information from the Ubuntu
> >> CVE tracker. Thanks Ubuntu!. If it doesn't have a hash that means it
> >> might not be fixed yet.
> >
> > [...]
> >
> >> CVE-2015-4170 cf872776fc84: tty: hang in tty
> >
> > Makes no sense that this was assigned a CVE.
> > I fixed this _2 yrs before_ it was reported and the patch was CC'd stable.
>
> I'm guessing the CVE was assigned because there are distributions that
> ship based on kernels earlier than 3.13. Those distributors need to
> verify if they have the fix, etc.
Yes, that's what happened here, Red Hat asked for it from what I
remember. I complained loudly on the oss-security list about it, but oh
well...
greg k-h
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [kernel-hardening] Re: 2015 kernel CVEs
2016-01-19 17:51 ` Greg KH
@ 2016-01-20 7:12 ` Marcus Meissner
0 siblings, 0 replies; 20+ messages in thread
From: Marcus Meissner @ 2016-01-20 7:12 UTC (permalink / raw)
To: kernel-hardening
Cc: Josh Boyer, Peter Hurley, Dan Carpenter,
Linux-Kernel@Vger. Kernel. Org
On Tue, Jan 19, 2016 at 09:51:54AM -0800, Greg KH wrote:
> On Tue, Jan 19, 2016 at 12:00:57PM -0500, Josh Boyer wrote:
> > On Tue, Jan 19, 2016 at 11:57 AM, Peter Hurley <peter@hurleysoftware.com> wrote:
> > > On 01/19/2016 03:28 AM, Dan Carpenter wrote:
> > >> I like to look back over old CVEs to see how we could do better. Here
> > >> is the list from 2015. I got most of this information from the Ubuntu
> > >> CVE tracker. Thanks Ubuntu!. If it doesn't have a hash that means it
> > >> might not be fixed yet.
> > >
> > > [...]
> > >
> > >> CVE-2015-4170 cf872776fc84: tty: hang in tty
> > >
> > > Makes no sense that this was assigned a CVE.
> > > I fixed this _2 yrs before_ it was reported and the patch was CC'd stable.
> >
> > I'm guessing the CVE was assigned because there are distributions that
> > ship based on kernels earlier than 3.13. Those distributors need to
> > verify if they have the fix, etc.
>
> Yes, that's what happened here, Red Hat asked for it from what I
> remember. I complained loudly on the oss-security list about it, but oh
> well...
The question for CVE assignment is more if this bug existed in shipped kernel releases, not
when it was fixed in relation to assignment.
Ciao, Marcus
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [kernel-hardening] 2015 kernel CVEs
2016-01-19 11:28 ` 2015 kernel CVEs Dan Carpenter
` (2 preceding siblings ...)
2016-01-19 16:57 ` Peter Hurley
@ 2016-01-19 17:57 ` Theodore Ts'o
2016-01-19 18:00 ` Al Viro
` (3 subsequent siblings)
7 siblings, 0 replies; 20+ messages in thread
From: Theodore Ts'o @ 2016-01-19 17:57 UTC (permalink / raw)
To: kernel-hardening; +Cc: linux-kernel
On Tue, Jan 19, 2016 at 02:28:12PM +0300, Dan Carpenter wrote:
> There was only a coupls CVEs that looks like they came from a filesystem
> fuzzer where you create a corrupt filesystems and then try use them.
> There was only one that might have come from a USB fuzzer. We probably
> should be testing those things better.
On Tue, Jan 19, 2016 at 12:49:17PM +0100, Hanno Böck wrote:
> I tried that, but it didn't lead to any results in the kernel [1].
> What I did:
> * Use filesystem checking tools (fsck) and fuzz them with afl
> * Use the queue created by afl and try to mount these with a
> kasan-enabled kernel
>
> My conclusion was that the filesystem code in the kernel is relatively
> robust (at least robust enough for this trivial fuzzing).
> But it led to a number of bugs discovered in filesystem fsck tools.
An engineer at Red Hat did a pretty exhaustive set of file system
fuzzing some 5 years or so ago (plus or minus; I'm a little fuzzy on
the dates). At the time he found a number of problems in ext4 and
other file systems, and those got fixed fairly promptly. (It was
great; he gave us sample file systems to reproduce the bug, so it was
pretty straightforward to find and fix the problems found during that
effort.)
The ext4 related 2015 CVE's were all due to code that went in more
recently, and partially in response to that, Darrick Wong contributed
ext4-specific fuzzers to xfstess and to e2fsprogs. I think he found
at least one or two ext4 bug that way, although I don't remember if
they got CVE's assigned to them.
Darrick's work, plus the relatively disciplined regression test suite
development policy in e2fsprogs is probably why Hanno didn't find any
such issues in e2fsprogs, although he did seem to find bugs in many of
the others file systems.
If I recall correctly Darrick had talked about trying to make a
filesystem-generic fuzzer for xfstests, but I'm not sure what happened
to that idea. It looks like he also did provide a set of fuzzing
tests in xfstests, though.
So while I wouldn't want to discourage people from spending more time
in doing file system fuzz tests (I really *love* it when people find
and report bugs to me :-), I suspect the reason why we aren't finding
as many file system related CVE's is that it's well trodden ground,
since it's a pretty easy / obvious place to start probing for
weaknesses. (And it's much easier than finding data races, for
example.)
If people do what to invest more in hardening file systems, I would
recommend automating the file system fuzz testers and then trying to
get the upstream file system developers to run them.
Cheers,
- Ted
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: 2015 kernel CVEs
2016-01-19 11:28 ` 2015 kernel CVEs Dan Carpenter
` (3 preceding siblings ...)
2016-01-19 17:57 ` [kernel-hardening] " Theodore Ts'o
@ 2016-01-19 18:00 ` Al Viro
2016-01-19 22:41 ` [kernel-hardening] " Eric W. Biederman
2016-01-19 22:47 ` [kernel-hardening] " Eric W. Biederman
` (2 subsequent siblings)
7 siblings, 1 reply; 20+ messages in thread
From: Al Viro @ 2016-01-19 18:00 UTC (permalink / raw)
To: Dan Carpenter; +Cc: linux-kernel, kernel-hardening, Eric W. Biederman
On Tue, Jan 19, 2016 at 02:28:12PM +0300, Dan Carpenter wrote:
> CVE-2015-4178 820f9f147dcc: fs_pin: uninitialized data
Why is that a CVE? Affected code is in pin_remove(), which is only
called from fs_pin ->kill() instances; if one is _ever_ called more
than once per fs_pin lifetime, we are already FUBAR. If Eric had
ever intended to add checks for hlist_unhashed() on those lists,
such checks never had been added to the tree. They definitely did not
exist at the moment when that commit went in.
It got merged mostly on the "it doesn't harm anything and it's a bit
more tidy that way" basis; if it had ever changed behaviour in any visible
way, *THEN* we had a real problem and that problem was not fixed by that
commit, so I would really like to see the details - simply to make sure
that the damn thing had been eventually fixed.
Eric, could you explain? And could whoever'd been responsible for
that CVE describe the process that had lead to its creation?
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [kernel-hardening] Re: 2015 kernel CVEs
2016-01-19 18:00 ` Al Viro
@ 2016-01-19 22:41 ` Eric W. Biederman
0 siblings, 0 replies; 20+ messages in thread
From: Eric W. Biederman @ 2016-01-19 22:41 UTC (permalink / raw)
To: Al Viro; +Cc: Dan Carpenter, kernel-hardening, linux-kernel
Al Viro <viro@ZenIV.linux.org.uk> writes:
> On Tue, Jan 19, 2016 at 02:28:12PM +0300, Dan Carpenter wrote:
>> CVE-2015-4178 820f9f147dcc: fs_pin: uninitialized data
>
> Why is that a CVE? Affected code is in pin_remove(), which is only
> called from fs_pin ->kill() instances; if one is _ever_ called more
> than once per fs_pin lifetime, we are already FUBAR. If Eric had
> ever intended to add checks for hlist_unhashed() on those lists,
> such checks never had been added to the tree. They definitely did not
> exist at the moment when that commit went in.
>
> It got merged mostly on the "it doesn't harm anything and it's a bit
> more tidy that way" basis; if it had ever changed behaviour in any visible
> way, *THEN* we had a real problem and that problem was not fixed by that
> commit, so I would really like to see the details - simply to make sure
> that the damn thing had been eventually fixed.
>
> Eric, could you explain? And could whoever'd been responsible for
> that CVE describe the process that had lead to its creation?
As best I know this was an issue because someone borked a backport,
and skipped this patch.
As I recall hlist_del_init was needed because in one instance one of the
lists was not used. Which is actually what it says in the description
of 820f9f147dcc so I will leave it at that.
Eric
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [kernel-hardening] 2015 kernel CVEs
2016-01-19 11:28 ` 2015 kernel CVEs Dan Carpenter
` (4 preceding siblings ...)
2016-01-19 18:00 ` Al Viro
@ 2016-01-19 22:47 ` Eric W. Biederman
2016-01-20 20:11 ` Jann Horn
2016-01-19 23:35 ` Kees Cook
2016-01-20 9:57 ` Miroslav Benes
7 siblings, 1 reply; 20+ messages in thread
From: Eric W. Biederman @ 2016-01-19 22:47 UTC (permalink / raw)
To: Dan Carpenter; +Cc: linux-kernel, kernel-hardening
Dan Carpenter <dan.carpenter@oracle.com> writes:
> I like to look back over old CVEs to see how we could do better. Here
> is the list from 2015. I got most of this information from the Ubuntu
> CVE tracker. Thanks Ubuntu!. If it doesn't have a hash that means it
> might not be fixed yet.
>
> CVE-2015-8709 : ptrace: race in user namespaces let's users trace root processes
As this isn't a kernel bug, and is not a race, and no one has even
bothered to see if any userspace processes are this stupid I don't even
think that qualifies as a CVE.
There is room for improvement in this area but I don't see how this
qualifies as a CVE.
So for doing better I recommend a little more vetting and paying
attention before assigning CVEs.
Eric
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [kernel-hardening] 2015 kernel CVEs
2016-01-19 22:47 ` [kernel-hardening] " Eric W. Biederman
@ 2016-01-20 20:11 ` Jann Horn
2016-01-20 21:26 ` One Thousand Gnomes
0 siblings, 1 reply; 20+ messages in thread
From: Jann Horn @ 2016-01-20 20:11 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Dan Carpenter, linux-kernel, kernel-hardening
[-- Attachment #1: Type: text/plain, Size: 4047 bytes --]
On Tue, Jan 19, 2016 at 04:47:32PM -0600, Eric W. Biederman wrote:
> Dan Carpenter <dan.carpenter@oracle.com> writes:
>
> > I like to look back over old CVEs to see how we could do better. Here
> > is the list from 2015. I got most of this information from the Ubuntu
> > CVE tracker. Thanks Ubuntu!. If it doesn't have a hash that means it
> > might not be fixed yet.
> >
> > CVE-2015-8709 : ptrace: race in user namespaces let's users trace root processes
>
> As this isn't a kernel bug,
I agree that it's not a kernel bug and not a kernel race - userspace
developers assumed security guarantees that the kernel didn't actually
provide.
However, I think that the kernel is missing documentation here and that
namespaces are designed somewhat unfortunately. A container that can be
created and securely, robustly entered by an unprivileged user would
have to work like this under the current rules as far as I can tell:
To create the container:
setsid
[prevent tty pushback via /dev/tty]
set up tty IO forwarding if necessary
[prevents tty pushback, possibly additional filtering]
unshare(CLONE_NEWUSER) to create a "purgatory" user ns.
Map the container owner to uid 0, map all uids that should be mapped into
the container (including the container root) to 1 and higher (where
1 is the container root).
stash FD to the purgatory user namespace somewhere in the outer ns
drop all privileges (open fds, ...)
setresuid(1,1,1) [still protected against ptrace by nondumpability]
unshare(CLONE_NEWUSER) to create the container's user ns
[From here on, we can be ptraced by the ns root user from outside.
The ns root user could ptrace us from outside at this point and
see the outer namespaces through us, but that's okay, he'd have
to already be in the outer user ns for that.]
set up other namespaces for the container
stash FDs to the container namespaces in the purgatory ns
let a process in the purgatory map the container uids and gids
do security-revelant setup work (setup bind mounts, ...)
[be careful here, don't trust any files in container-controlled
filesystem parts]
do security-irrelevant setup work
execlp("init")
Then, to enter the container:
setsid
[prevent tty pushback via /dev/tty]
set up tty IO forwarding if necessary
[prevents tty pushback, possibly additional filtering]
Enter the purgatory user ns, referenced through an FD
setresuid(1, 1, 1) [still protected against ptrace by nondumpability]
enter container namespaces, but not the user namespace yet
[We don't really trust the namespace FDs supplied by the setup
process because they were sent after the ns root user gained
ptrace access, but that's okay because we can only move downward
using setns(), so we end up in namespaces below the purgatory
that are owned by the namespace root. That's good enough.]
drop privileges (open fds, ...)
enter container user namespace [ns root gains ptrace access]
The purgatory user ns is necessary because without privileges in the
container's parent user namespace, it's not possible to switch to the
container root uid prior to entering it (except with an ugly hack
involving a temporary namespace, newuidmap and a (possibly temporary)
setuid binary), and more importantly, even given access to the
container's root uid, it's not possible to actually enter the
container without having the container owner's euid unless you have
CAP_SYS_ADMIN in the outer namespace.
(Of course, this could be simplified with a setuid root helper, but I
don't think anyone wants more of those to be necessary.)
> and is not a race, and no one has even
> bothered to see if any userspace processes are this stupid I don't even
> think that qualifies as a CVE.
I know of at least two projects that enter user namespaces without the
necessary care, one of them is LXC.
> There is room for improvement in this area but I don't see how this
> qualifies as a CVE.
I think I agree with that.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [kernel-hardening] 2015 kernel CVEs
2016-01-20 20:11 ` Jann Horn
@ 2016-01-20 21:26 ` One Thousand Gnomes
0 siblings, 0 replies; 20+ messages in thread
From: One Thousand Gnomes @ 2016-01-20 21:26 UTC (permalink / raw)
To: Jann Horn
Cc: Eric W. Biederman, Dan Carpenter, linux-kernel, kernel-hardening
> I know of at least two projects that enter user namespaces without the
> necessary care, one of them is LXC.
>
>
> > There is room for improvement in this area but I don't see how this
> > qualifies as a CVE.
>
> I think I agree with that.
If there are projects that screw it up then there should be a CVE - it
just needs someone to update the CVE to indicate where the actual flaw is.
Alan
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [kernel-hardening] 2015 kernel CVEs
2016-01-19 11:28 ` 2015 kernel CVEs Dan Carpenter
` (5 preceding siblings ...)
2016-01-19 22:47 ` [kernel-hardening] " Eric W. Biederman
@ 2016-01-19 23:35 ` Kees Cook
2016-01-20 9:57 ` Miroslav Benes
7 siblings, 0 replies; 20+ messages in thread
From: Kees Cook @ 2016-01-19 23:35 UTC (permalink / raw)
To: kernel-hardening@lists.openwall.com; +Cc: LKML, Laura Abbott
On Tue, Jan 19, 2016 at 3:28 AM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> Many of the use-after-free and uninitialized data bugs would be less
> harmful if we had some kernel hardening patches.
I think this nicely underscores the importance of all the hardening
efforts, especially Laura's PAX_MEMORY_SANITIZE port. And with the
recent keyring issue, having David's PAX_REFCOUNT port too. It's all
coming along (slowly). :)
-Kees
--
Kees Cook
Chrome OS & Brillo Security
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: 2015 kernel CVEs
2016-01-19 11:28 ` 2015 kernel CVEs Dan Carpenter
` (6 preceding siblings ...)
2016-01-19 23:35 ` Kees Cook
@ 2016-01-20 9:57 ` Miroslav Benes
7 siblings, 0 replies; 20+ messages in thread
From: Miroslav Benes @ 2016-01-20 9:57 UTC (permalink / raw)
To: Dan Carpenter; +Cc: linux-kernel, kernel-hardening
On Tue, 19 Jan 2016, Dan Carpenter wrote:
> CVE-2015-3339 : fs: race condition between chown and execve
FWIW, fixed by 8b01fc86b9f4 ("fs: take i_mutex during prepare_binprm for
set[ug]id executables").
Regards,
Miroslav
^ permalink raw reply [flat|nested] 20+ messages in thread