Two Serious Vulnerabilities Hit the Linux Kernel
Security researchers publicly disclosed two serious vulnerabilities in the Linux kernel that could allow local attackers to obtain root privileges on Linux systems.
The first vulnerability was discovered by researchers from security firm Qualys and is tracked as CVE-2018-14634. The flaw is located in Linux kernel’s create_elf_tables() function and can be exploited on 64-bit systems by local users with access to SUID binaries.
According to Qualys’ researchers, who named this vulnerability Mutagen Astronomy, the bug existed in the Linux kernel for around a decade. It was introduced with commit b6a2fea39318 (mm: variable length argument support) on July 19, 2007, and happened to be mitigated on July 7, 2017, through another patch: da029c11e6b1 (exec: Limit arg stack to at most 75 percent of _STK_LIM).
However, it turns out that not all Linux distributions backported the da029c11e6b1 commit into their kernels and remained vulnerable. Among the distributions affected when this flaw disclosed this week are Red Hat Enterprise Linux (RHEL) 6, 7 and Red Hat Enterprise MRG 2, as well CentOS, which is based on RHEL and Debian 8 Jessie (oldstable).
“This issue does not affect 32-bit systems as they do not have a large enough address space to exploit this flaw,” Red Hat said in a security advisory. “Systems with less than 32GB of memory are very unlikely to be affected by this issue due to memory demands during exploitation.”
Red Hat plans to fix the issue in a future kernel update, but until then, its advisory contains a manual workaround that will protect systems against exploitation. The workaround needs to be reapplied after system reboots.
The second vulnerability, tracked as CVE-2018-17182, was found by Jann Horn, a security researcher with Google’s Project Zero. The flaw can also be exploited to achieve arbitrary code execution as root and affects all kernel versions since 3.16.
Horn showed how the vulnerability can be exploited on kernels that haven’t been configured for increased security, but warned that with additional effort, the code that can trigger this bug can also be reached from within sandboxed contexts: seccomp, the sandbox of the main gVisor host component and Docker’s seccomp policy.
“To make things easy, my exploit uses various other kernel interfaces, and therefore doesn’t just work from inside such sandboxes; in particular, it uses /dev/kmsg to read dmesg logs and uses an eBPF array to spam the kernel’s page allocator with user-controlled, mutable single-page allocations,” Horn said in a blog post. “However, an attacker willing to invest more time into an exploit would probably be able to avoid using such interfaces.”
The bug was reported to the Linux kernel maintainers on Sept. 12 and a patch for it was created two days later, which Horn described as “exceptionally fast” compared to the fix times of other software vendors.
However, he also pointed to a well-known problem in the Linux ecosystem that is also highlighted by the Mutagen Astronomy flaw: When a vulnerability is patched in the upstream Linux kernel it doesn’t automatically mean that users’ systems are protected.
In fact, it can take a significant amount of time until end-user systems receive the patch. That’s because most users use a particular Linux distribution and rely on receiving security patches through it. These Linux distributions generally use stable kernels, including older ones, so they need to wait until the maintainers of those kernels backport the fixes.
All these delays create a window of opportunity for attackers, and sometimes, like in the Mutagen Astronomy case, some patches that might not look very important for a distribution to import could turn out to have security implications years later.
The patch for Horn’s CVE-2018-17182 flaw was backported to the stable kernels 4.18, 4.14, 4.9 and 4.4 on Sept. 19, four days after the flaw effectively became public through the upstream patch. However, when Horn published his detailed blog post and exploit, on Sept. 26, Debian stable still used a 4.9 kernel that hadn’t been updated since Aug. 21, while Ubuntu 16.04 shipped a kernel that hadn’t been updated since Aug. 27.
