2015 kernel CVEs

2015 kernel CVEs

[Dan Carpenter]

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-5707 451a2886b6bf fdc81f45e9f5: scsi/sg: integer overflow leading to buffer overflow (iovec)
CVE-2015-5257 cbb4be652d37: usb/whiteheat: NULL deref with bad hardware.
CVE-2015-6252 7932c0bd7740: vhost: resource leak. DoS
CVE-2015-5366 beb39db59d14: udp: not yielding the CPU. DoS udp: duplicate of CVE-2015-5366?
CVE-2015-4700 3f7352bf21f8: bpf: NULL deref on corner case.
CVE-2015-7872 f05819df10d7: keys: uninitialized data
CVE-2015-4178 820f9f147dcc: fs_pin: uninitialized data
CVE-2015-4002 d114b9fe78c8 9a59029bc218: staging/ozwpan: buffer overflow
CVE-2015-7799 0baa57d8dc32 4ab42d78e37a: ppp: bad bounds check leads to NULL deref. (root only normally).
CVE-2015-3290 9b6e6a8334d5: nmi: nested NMI is problematic
CVE-2015-2041 6b8d9117ccb4: net: llc: bounds error leads to info leak
CVE-2015-4003 04bf464a5dfd: staging/ozwpan: divide by zero
CVE-2015-3331 ccfe8c3f7e52: crypto/aesni: buffer overflow because of math error
CVE-2015-4001 b1bb5b49373b: staging/ozwpan: array underflow write
CVE-2015-6526 9a5cbce421a2: powerpc/perf: forever loop
CVE-2015-0239 f3747379accb: KVM: x86: uninitialized data
CVE-2015-4176 e0c9c0afd2fc: mnt: flaw in logic
CVE-2015-2150 af6fc858a35b: xen-pciback: accidentally gave too much power
CVE-2015-3339 : fs: race condition between chown and execve
CVE-2015-2830 956421fbb74c: x86/asm/entry/64: faw in assembly logic
CVE-2015-4692 ce40cd3fc7fa: kvm: x86: NULL deref
CVE-2015-4170 cf872776fc84: tty: hang in tty
CVE-2015-1350 : fs: some attributes are managed by chown some by the lsm
CVE-2015-0275 0f2af21aae11: ext4: BUG() alignment issue when page size larger than block size
CVE-2015-5706 f15133df088e: path_openat: double free
CVE-2015-4177 cd4a40174b71: mnt: flaw in logic with namespaces (crash I guess).
CVE-2015-6937 74e98eb08588: RDS: NULL deref
CVE-2015-2925 cde93be45a8a 397d425dc26d: vfs: logic flaw handling path names
CVE-2015-3636 a134f083e79f: ipv4: use after free leads to NULL deref
CVE-2015-2877 : kvm: ASLR base address leak of co-located VMs.
CVE-2013-2015 0e9a9a1ad619: ext4: hang during mount
CVE-2015-5157 9b6e6a8334d5: x86/nmi/64: nested NMI problems
CVE-2015-1420 161f873b8913: vfs: bounds checking error leads to serious info leak
CVE-2015-1421 600ddd682554: net/sctp: double free
CVE-2015-7613 b9a532277938: ipc/msg: uninitialized data
CVE-2015-4004 a73e99cb67e7: staging/ozwpan: we just deleted the driver
CVE-2015-3212 2d45a02d0166: net/sctp: race condition
CVE-2015-3291 810bc075f78f: x86/nmi/64: more nested NMI issues
CVE-2015-4167 23b133bdc452: fs/udf: trusting the disk (missing range checks)
CVE-2015-1805 f0d1bec9d58d 637b58c2887e: fs/pipe: bad error handling leads to buffer overflow
CVE-2015-1333 ca4da5dd1f99: keys: memory leak
CVE-2015-2042 db27ebb111e9: net/rds: using wrong bounds leads to info leak
CVE-2015-5283 8e2d61e0aed2: net/sctp: uninitialized data. life cycle issues.
CVE-2015-5697 b6878d9e0304: md: not zeroing memory from kmalloc() leads to info leak
CVE-2015-5364 beb39db59d14: udp: duplicate of CVE-2015-5366?
CVE-2015-4036 59c816c1f24d: vhost/scsi: wrong bounds limit
CVE-2015-5156 48900cb6af42: virtio-net: logic flaw leads to buffer overflow
CVE-2015-2922 6fd99094de2b: ipv6: logic flaw leads to dropped packets
CVE-2015-1593 4e7c22d447bb: ASLR: shift truncation leads to not enough ASLR
CVE-2015-1573 a2f18db0c68f: netfilter/nf_tables: use after free
CVE-2015-2686 4de930efc23b: net: missing access_ok() checks
CVE-2015-2672 06c8173eb92b: x86/fpu/xsaves: logic flaw in assembly leads to DoS
CVE-2015-1465 df4d92549f23: ipv4: logic flaw with RCU leading to DoS
CVE-2015-2666 f84598bd7c85: x86/microcode/intel: missing bounds check verifying microcode
CVE-2015-0274 8275cdd0e7ac: xfs: using wrong bounds
CVE-2015-8215 77751427a1ff: ipv6: setting wrong mtu causes packet loss
CVE-2015-7885 4b6184336ebb: staging/dgnc: info leak
CVE-2015-7884 eda98796aff0: media/vivid: info leak
CVE-2015-7509 c9b92530a723 0e9a9a1ad619: ext4: hang on mount
CVE-2015-8575 : net/bluetooth: still private
CVE-2015-7513 0185604c2d82: KVM: uninitialized data leads to mod by zero
CVE-2015-8324 744692dc0598: ext4: NULL deref mounting file systems
CVE-2015-5307 54a20552e1ea: KVM: forever loop
CVE-2015-7550 b4a1b4f5047e: KEYS: Race condition
CVE-2015-8569 09ccfd238e5a: pptp: underflow leads to serious information leak
CVE-2015-8660 acff81ec2c79: ovl: logic flaw in checking permisions
CVE-2015-8374 0305cd5f7fca: Btrfs: logic flaw in truncate leads to information leak
CVE-2015-8539 096fe9eaea40: Keys: uninitialized data leads to bad dereference
CVE-2015-8709 : ptrace: race in user namespaces let's users trace root processes
CVE-2015-8746 18e3b739fdc8: NFS: NULL deref. missing function pointer.
CVE-2015-8104 cbdb967af3d5: kvm: guest can make the host hang
CVE-2015-8767 635682a14427: sctp: lockup
CVE-2015-7990 8c7188b23474: RDS: race condition leads to NULL deref
CVE-2015-5327 cc25b994acfb: X.509: off by one read leads to badness
CVE-2015-8543 79462ad02e86: ipv4: bad range checking leads to NULL deref

There are several ways that CVEs are assigned.  The person who discovers
the bug can get it from oss-security.  If bugs are reported to
security@kernel.org they get forwarded to linux-distros who allocates a
CVE.  Distributions look through the stable patches and file for CVEs.
A few maintainers apply for CVEs, notably the KVM devs and I think David
Howells.

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 was one CVE from Smatch.  Smatch has improved, inspired by the
ozwpan bugs and hopefully could catch most of those bounds errors now.

Quite a few bugs were found using the Trinity fuzzer.  Also the new
syzkaller fuzzer seems to have found a bunch of stuff.  Good work.  I
think people are using the fuzzers with kasan as well which is a
fantastic tool.

Many of the use-after-free and unintialized data bugs would be less
harmful if we had some kernel hardenning patches.

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.

regards,
dan carpenter

[kernel-hardening] 2015 kernel CVEs

[Dan Carpenter]

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-5707 451a2886b6bf fdc81f45e9f5: scsi/sg: integer overflow leading to buffer overflow (iovec)
CVE-2015-5257 cbb4be652d37: usb/whiteheat: NULL deref with bad hardware.
CVE-2015-6252 7932c0bd7740: vhost: resource leak. DoS
CVE-2015-5366 beb39db59d14: udp: not yielding the CPU. DoS udp: duplicate of CVE-2015-5366?
CVE-2015-4700 3f7352bf21f8: bpf: NULL deref on corner case.
CVE-2015-7872 f05819df10d7: keys: uninitialized data
CVE-2015-4178 820f9f147dcc: fs_pin: uninitialized data
CVE-2015-4002 d114b9fe78c8 9a59029bc218: staging/ozwpan: buffer overflow
CVE-2015-7799 0baa57d8dc32 4ab42d78e37a: ppp: bad bounds check leads to NULL deref. (root only normally).
CVE-2015-3290 9b6e6a8334d5: nmi: nested NMI is problematic
CVE-2015-2041 6b8d9117ccb4: net: llc: bounds error leads to info leak
CVE-2015-4003 04bf464a5dfd: staging/ozwpan: divide by zero
CVE-2015-3331 ccfe8c3f7e52: crypto/aesni: buffer overflow because of math error
CVE-2015-4001 b1bb5b49373b: staging/ozwpan: array underflow write
CVE-2015-6526 9a5cbce421a2: powerpc/perf: forever loop
CVE-2015-0239 f3747379accb: KVM: x86: uninitialized data
CVE-2015-4176 e0c9c0afd2fc: mnt: flaw in logic
CVE-2015-2150 af6fc858a35b: xen-pciback: accidentally gave too much power
CVE-2015-3339 : fs: race condition between chown and execve
CVE-2015-2830 956421fbb74c: x86/asm/entry/64: faw in assembly logic
CVE-2015-4692 ce40cd3fc7fa: kvm: x86: NULL deref
CVE-2015-4170 cf872776fc84: tty: hang in tty
CVE-2015-1350 : fs: some attributes are managed by chown some by the lsm
CVE-2015-0275 0f2af21aae11: ext4: BUG() alignment issue when page size larger than block size
CVE-2015-5706 f15133df088e: path_openat: double free
CVE-2015-4177 cd4a40174b71: mnt: flaw in logic with namespaces (crash I guess).
CVE-2015-6937 74e98eb08588: RDS: NULL deref
CVE-2015-2925 cde93be45a8a 397d425dc26d: vfs: logic flaw handling path names
CVE-2015-3636 a134f083e79f: ipv4: use after free leads to NULL deref
CVE-2015-2877 : kvm: ASLR base address leak of co-located VMs.
CVE-2013-2015 0e9a9a1ad619: ext4: hang during mount
CVE-2015-5157 9b6e6a8334d5: x86/nmi/64: nested NMI problems
CVE-2015-1420 161f873b8913: vfs: bounds checking error leads to serious info leak
CVE-2015-1421 600ddd682554: net/sctp: double free
CVE-2015-7613 b9a532277938: ipc/msg: uninitialized data
CVE-2015-4004 a73e99cb67e7: staging/ozwpan: we just deleted the driver
CVE-2015-3212 2d45a02d0166: net/sctp: race condition
CVE-2015-3291 810bc075f78f: x86/nmi/64: more nested NMI issues
CVE-2015-4167 23b133bdc452: fs/udf: trusting the disk (missing range checks)
CVE-2015-1805 f0d1bec9d58d 637b58c2887e: fs/pipe: bad error handling leads to buffer overflow
CVE-2015-1333 ca4da5dd1f99: keys: memory leak
CVE-2015-2042 db27ebb111e9: net/rds: using wrong bounds leads to info leak
CVE-2015-5283 8e2d61e0aed2: net/sctp: uninitialized data. life cycle issues.
CVE-2015-5697 b6878d9e0304: md: not zeroing memory from kmalloc() leads to info leak
CVE-2015-5364 beb39db59d14: udp: duplicate of CVE-2015-5366?
CVE-2015-4036 59c816c1f24d: vhost/scsi: wrong bounds limit
CVE-2015-5156 48900cb6af42: virtio-net: logic flaw leads to buffer overflow
CVE-2015-2922 6fd99094de2b: ipv6: logic flaw leads to dropped packets
CVE-2015-1593 4e7c22d447bb: ASLR: shift truncation leads to not enough ASLR
CVE-2015-1573 a2f18db0c68f: netfilter/nf_tables: use after free
CVE-2015-2686 4de930efc23b: net: missing access_ok() checks
CVE-2015-2672 06c8173eb92b: x86/fpu/xsaves: logic flaw in assembly leads to DoS
CVE-2015-1465 df4d92549f23: ipv4: logic flaw with RCU leading to DoS
CVE-2015-2666 f84598bd7c85: x86/microcode/intel: missing bounds check verifying microcode
CVE-2015-0274 8275cdd0e7ac: xfs: using wrong bounds
CVE-2015-8215 77751427a1ff: ipv6: setting wrong mtu causes packet loss
CVE-2015-7885 4b6184336ebb: staging/dgnc: info leak
CVE-2015-7884 eda98796aff0: media/vivid: info leak
CVE-2015-7509 c9b92530a723 0e9a9a1ad619: ext4: hang on mount
CVE-2015-8575 : net/bluetooth: still private
CVE-2015-7513 0185604c2d82: KVM: uninitialized data leads to mod by zero
CVE-2015-8324 744692dc0598: ext4: NULL deref mounting file systems
CVE-2015-5307 54a20552e1ea: KVM: forever loop
CVE-2015-7550 b4a1b4f5047e: KEYS: Race condition
CVE-2015-8569 09ccfd238e5a: pptp: underflow leads to serious information leak
CVE-2015-8660 acff81ec2c79: ovl: logic flaw in checking permisions
CVE-2015-8374 0305cd5f7fca: Btrfs: logic flaw in truncate leads to information leak
CVE-2015-8539 096fe9eaea40: Keys: uninitialized data leads to bad dereference
CVE-2015-8709 : ptrace: race in user namespaces let's users trace root processes
CVE-2015-8746 18e3b739fdc8: NFS: NULL deref. missing function pointer.
CVE-2015-8104 cbdb967af3d5: kvm: guest can make the host hang
CVE-2015-8767 635682a14427: sctp: lockup
CVE-2015-7990 8c7188b23474: RDS: race condition leads to NULL deref
CVE-2015-5327 cc25b994acfb: X.509: off by one read leads to badness
CVE-2015-8543 79462ad02e86: ipv4: bad range checking leads to NULL deref

There are several ways that CVEs are assigned.  The person who discovers
the bug can get it from oss-security.  If bugs are reported to
security@kernel.org they get forwarded to linux-distros who allocates a
CVE.  Distributions look through the stable patches and file for CVEs.
A few maintainers apply for CVEs, notably the KVM devs and I think David
Howells.

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 was one CVE from Smatch.  Smatch has improved, inspired by the
ozwpan bugs and hopefully could catch most of those bounds errors now.

Quite a few bugs were found using the Trinity fuzzer.  Also the new
syzkaller fuzzer seems to have found a bunch of stuff.  Good work.  I
think people are using the fuzzers with kasan as well which is a
fantastic tool.

Many of the use-after-free and unintialized data bugs would be less
harmful if we had some kernel hardenning patches.

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.

regards,
dan carpenter

Re: [kernel-hardening] 2015 kernel CVEs

[Hanno Böck]

[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]

On Tue, 19 Jan 2016 14:28:12 +0300
Dan Carpenter <dan.carpenter@oracle.com> 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.

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.

> There was only one that might have come from a USB fuzzer.
> We probably should be testing those things better.

This is surprising to me. There was a talk at black hat amsterdam in
2014 about a project trying to do exactly this. They sounded like they
have dozends of crashers that just need to be sorted and reported
upstream. Here's the code [2] and the talk [3].
Maybe this project has stalled and needs someone to look at it?

[1]
https://www.coreinfrastructure.org/sites/cii/files/pages/files/2015-09-fuzzing-report.pdf
[2] https://github.com/schumilo/vUSBf
[3] https://www.youtube.com/watch?v=OAbzN8k6Am4


-- 
Hanno Böck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [kernel-hardening] 2015 kernel CVEs

[Wade Mealing]

[-- Attachment #1: Type: text/plain, Size: 406 bytes --]

>
>
>
> Quite a few bugs were found using the Trinity fuzzer.  Also the new
> syzkaller fuzzer seems to have found a bunch of stuff.  Good work.  I
> think people are using the fuzzers with kasan as well which is a
> fantastic tool.
>
>
One of the unsung heros that frequently assisted in discovery in some of
these issues were ktsan.

Thanks for the nice writeup,

Wade Mealing

-- 
Thanks,

Wade Mealing

[-- Attachment #2: Type: text/html, Size: 749 bytes --]

Re: 2015 kernel CVEs

[One Thousand Gnomes]

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

[kernel-hardening] Re: 2015 kernel CVEs

[One Thousand Gnomes]

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

Re: [kernel-hardening] 2015 kernel CVEs

[Quentin Casasnovas]

On Tue, Jan 19, 2016 at 12:49:17PM +0100, Hanno Böck wrote:
> On Tue, 19 Jan 2016 14:28:12 +0300
> Dan Carpenter <dan.carpenter@oracle.com> 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.
> 
> 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.
> 

As an experimental toy project, we've managed to implement the glue to have
AFL run on the kernel code, using either a patched afl-as wrapper or a
slightly modified GCC extension written by Dmitry Vyukov for syzkaller
(-fsanitize-coverage=trace-pc), and our conclusion is quite different.

In the month Vegard Nossum has been using it, he reported at least a dozen
problems at mount or readdir time:

btrfs:
 https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg48448.html
 https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg48976.html
 https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg49011.html

ext4:
 http://marc.info/?l=linux-ext4&m=144898824424465&w=2
 https://lkml.org/lkml/2015/12/13/187

hfs:
 http://marc.info/?l=linux-fsdevel&m=144900215929323&w=2

isofs:
 https://marc.info/?l=linux-kernel&m=144933509518680&w=2

udf:
 https://lkml.org/lkml/2015/12/10/438
 https://lkml.org/lkml/2015/12/11/526

vfat:
 https://lkml.org/lkml/2015/11/13/782
 https://lkml.org/lkml/2015/11/23/36

xfs:
 https://marc.info/?l=linux-xfs&m=144904267207656&w=2

It should be noted that most of these problems were found relatively
quickly and without changing much the filesystem code, checksums weren't
disabled for example a part for superblock checksum in btrfs.  And that was
mostly fuzzing the mount/readdir syscalls so a lot more can probably be
found there.

Thanks,
Quentin

Re: [kernel-hardening] 2015 kernel CVEs

[Ben Hutchings]

[-- 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 --]

Re: 2015 kernel CVEs

[Peter Hurley]

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

[kernel-hardening] Re: 2015 kernel CVEs

[Peter Hurley]

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

Re: 2015 kernel CVEs

[Josh Boyer]

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

[kernel-hardening] Re: 2015 kernel CVEs

[Josh Boyer]

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

Re: 2015 kernel CVEs

[Greg KH]

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

[kernel-hardening] Re: 2015 kernel CVEs

[Greg KH]

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

Re: [kernel-hardening] 2015 kernel CVEs

[Greg KH]

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

Re: [kernel-hardening] 2015 kernel CVEs

[Theodore Ts'o]

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

Re: 2015 kernel CVEs

[Al Viro]

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?

[kernel-hardening] Re: 2015 kernel CVEs

[Al Viro]

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?

Re: [kernel-hardening] Re: 2015 kernel CVEs

[Eric W. Biederman]

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

Re: [kernel-hardening] 2015 kernel CVEs

[Eric W. Biederman]

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

Re: [kernel-hardening] 2015 kernel CVEs

[Kees Cook]

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

Re: [kernel-hardening] 2015 kernel CVEs

[Kees Cook]

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

Re: [kernel-hardening] Re: 2015 kernel CVEs

[Marcus Meissner]

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

Re: 2015 kernel CVEs

[Miroslav Benes]

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

[kernel-hardening] Re: 2015 kernel CVEs

[Miroslav Benes]

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

Re: [kernel-hardening] 2015 kernel CVEs

[Hanno Böck]

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

On Tue, 19 Jan 2016 12:49:17 +0100
Hanno Böck <hanno@hboeck.de> wrote:

> > There was only one that might have come from a USB fuzzer.
> > We probably should be testing those things better.  
> 
> This is surprising to me. There was a talk at black hat amsterdam in
> 2014 about a project trying to do exactly this. They sounded like they
> have dozends of crashers that just need to be sorted and reported
> upstream. Here's the code [2] and the talk [3].

https://packetstormsecurity.com/files/133892/RedHat-Enterprise-Linux-7.1-Denial-Of-Service.html

It seems they have started reporting issues and got limited replies.


-- 
Hanno Böck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [kernel-hardening] 2015 kernel CVEs

[Wade Mealing]

[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]

On Wed, Jan 20, 2016 at 9:19 PM Hanno Böck <hanno@hboeck.de> wrote:

> On Tue, 19 Jan 2016 12:49:17 +0100
> Hanno Böck <hanno@hboeck.de> wrote:
>
> > > There was only one that might have come from a USB fuzzer.
> > > We probably should be testing those things better.
> >
> > This is surprising to me. There was a talk at black hat amsterdam in
> > 2014 about a project trying to do exactly this. They sounded like they
> > have dozends of crashers that just need to be sorted and reported
> > upstream. Here's the code [2] and the talk [3].
>
>
> https://packetstormsecurity.com/files/133892/RedHat-Enterprise-Linux-7.1-Denial-Of-Service.html
>
> It seems they have started reporting issues and got limited replies.
>
>
Disclaimer: I work for Red Hat Product Security group in the kernel sub
group with Vladis.

So from what I can see:

- The CVE has been assigned.
- A kernel has been built with a patch
- Communicated with upstream about accepting the patch.
- The issue is awaiting testing on the reporter since 24th of November last
year.
- This is not the only bugs that has been reported and worked between Ralf
and Vladis ( https://goo.gl/5G1cnw )

I'm all about improving process, I imagine I would have done the same
steps.   What changes to the responses would need to be made to be less
limited ?  Understand that i'm not taking this personally and consider this
an opportunity for Red Hat Security to improve as a group.

If you want to take this off list, I'm cool with that.

Thanks,

Wade Mealing
-- 
Thanks,

Wade Mealing

[-- Attachment #2: Type: text/html, Size: 2381 bytes --]

Re: [kernel-hardening] 2015 kernel CVEs

[Ben Hutchings]

[-- 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 --]

Re: [kernel-hardening] 2015 kernel CVEs

[Hanno Böck]

[-- Attachment #1: Type: text/plain, Size: 945 bytes --]

On Wed, 20 Jan 2016 14:15:14 +0000
Wade Mealing <wmealing@gmail.com> wrote:

> I'm all about improving process, I imagine I would have done the same
> steps.   What changes to the responses would need to be made to be
> less limited ?  Understand that i'm not taking this personally and
> consider this an opportunity for Red Hat Security to improve as a
> group.

Just to make this clear, I was not involved at all. I based my
statement purely on publicly available information from the advisory
that says:
"We unsuccessfully tried to contact the vendor for several months. We
never received any response on our bugtraq ticket:"

So I'm not the right person to discuss what went wrong in the process.

FWIW I tried to reach out to one of the people doing this research
(Sergej Schumilo) and hope we can make sure these issues get tackled.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [kernel-hardening] 2015 kernel CVEs

[Greg KH]

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

Re: [kernel-hardening] 2015 kernel CVEs

[Jann Horn]

[-- 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 --]

Re: [kernel-hardening] 2015 kernel CVEs

[One Thousand Gnomes]

> 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

Re: [kernel-hardening] 2015 kernel CVEs

[Jiri Kosina]

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

Re: [kernel-hardening] 2015 kernel CVEs

[Ben Hutchings]

[-- 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 --]