Date: Thu, 2 Aug 2018 20:57:07 +0200 From: Andrey Konovalov <andreyknvl@...il.com> To: oss-security@...ts.openwall.com Cc: Kostya Serebryany <kcc@...gle.com>, Dmitry Vyukov <dvyukov@...gle.com>, Alexander Potapenko <glider@...gle.com>, keescook@...gle.com Subject: Linux kernel: CVE-2017-18344: arbitrary-read vulnerability in the timer subsystem Hi! Syzkaller/syzbot found a global-out-of-bounds bug in the timer subsystem of the Linux kernel , that is exploitable and can be used to gain an arbitrary-read primitive. This allows to access kernel memory and leak keys, credentials or other sensitive information that is stored there (so the bug has a similar impact to Meltdown). I'll share a PoC exploit in a week. The bug was introduced in commit 57b8015e ("posix-timers: Show sigevent info in proc file")  in 3.10 and fixed by commit cef31d9a ("posix-timer: Properly check sigevent->sigev_notify")  in 4.15-rc4. The bug only affects kernels that have CONFIG_POSIX_TIMERS and CONFIG_CHECKPOINT_RESTORE enabled, which is done by a lot of modern distros. This bug has been fixed in Ubuntu 16.04 , but still affects at least CentOS 7 at this moment (at least 3.10.0-862.9.1.el7.x86_64 that I've checked). I haven't checked the other distros. I've contacted linux-distros@ today and was asked to post to oss-security@ right away, since the issue is already public (and has been for the last 8 months, see the timeline below). ====== Description from MITRE : The timer_create syscall implementation in kernel/time/posix-timers.c in the Linux kernel before 4.14.8 doesn't properly validate the sigevent->sigev_notify field, which leads to out-of-bounds access in the show_timer function (called when /proc/$PID/timers is read). This allows userspace applications to read arbitrary kernel memory (on a kernel built with CONFIG_POSIX_TIMERS and CONFIG_CHECKPOINT_RESTORE). ====== I thought it would be quite interesting to see when some Linux distros fixed this bug, since there was no CVE requested and assigned until recently. Initially I was only looking at Ubuntu 16.04, here's the related timeline: * Nov 30, 2017 - the bug reported by syzbot  * Dec 15, 2017 - the fix committed upstream  * Feb 17, 2018 - the fix backported to the 4.4 stable kernel branch  * Mar 15, 2018 - the fix added to the Ubuntu Xenial 4.4 kernel branch  * Jul 25, 2018 - CVE requested * Aug 2, 2018 - notified linux-distros@ * Aug 2, 2018 - announcement on oss-security@ In this particular case of a somewhat "scary" bug there was a window of 3.5 months between the bug being reported and the fixing commit reaching the Ubuntu Xenial 4.4 kernel branch. This gives some insight into how much time it usually takes for a fix to travel from upstream through stable into a distro kernel when there's no CVE. Compared to the 14 days, that distros are usually given to fix a security bug reported through linux-distros@, that seems rather long. Then I decided to take a look at the CentOS kernel. I was quite surprised to find out that this bug hasn't been fixed there at all. I was under the impression that most Linux distros either follow stable kernel branches or monitor upstream commits for security related fixes themselves. It seems that this is not the case. Perhaps this fix was missed because CentOS 7 kernel is based on the 3.10 kernel version, and the 3.10 stable kernel release stopped being supported in November 2017. This is just one bug though. Right now there are 700+ fixed bugs reported by syzbot  and 200+ more, which are still not fixed . Almost none of them have CVEs (if anybody want to practice requesting CVEs, go for it). There are also ~9000 fixes backported to 4.4 stable kernel. Some of them are security relevant and don't have CVEs. On top of that apparently there are ~700 fixes that are missing in the 4.4 stable kernel . It seems that a CVE is required for a particular security related fix to end up in distro kernels, but there are no CVEs requested for most of the bugs that are being fixed. So there's this inconsistency between the Linux kernel community that just fixes the bugs without bothering about CVEs and the distros, which require CVEs to apply fixes to their kernels. Just some thoughts :) Thanks! ======  https://syzkaller.appspot.com/bug?id=e4cd90db60c4517094c0ffcb9468de1bf86809e7  https://github.com/torvalds/linux/commit/57b8015e07a70301e9ec9f324db1a8b73b5a1e2b  https://github.com/torvalds/linux/commit/cef31d9af908243421258f1df35a4a644604efbe  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-18344  https://groups.google.com/d/msg/syzkaller-bugs/9mUyHIix2ys/bTLPoT-kAgAJ  https://lkml.org/lkml/2018/2/17/139  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1756121  https://syzkaller.appspot.com/  https://syzkaller.appspot.com/?fixed=upstream  https://twitter.com/grsecurity/status/1022599945604526087
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