CVE-2018-1718 -Google Project Zero reports a new Linux Kernel flaw
Google Project Zero disclosed details for a high severity Linux kernel a use-after-free vulnerability tracked as CVE-2018-1718.
The vulnerability is a use-after-free tracked as CVE-2018-17182, it was discovered by Google Project Zero’s Jann Horn. The vulnerability was introduced in August 2014 with the release of version 3.16 of the Linux kernel.
The issue could be exploited by an attacker trigger a DoS condition or to execute arbitrary code with root privileges on the vulnerable system.
The expert reported the flaws to Linux kernel development team on September 12 and they fixed it in just two days later.
Horn also published the PoC exploit for the vulnerability, the researcher explained that exploitation of the issue is time-consuming because the process triggering the vulnerability needs to run for long enough to cause the overflow for a reference counter.
“This blogpost describes a way to exploit a Linux kernel bug (CVE-2018-17182) that exists since kernel version 3.16.” reads the security advisory published by Project Zero.
“Fixes for the issue are in the upstream stable releases 4.18.9, 4.14.71, 4.9.128, 4.4.157 and 3.16.58.”
The researcher warns of the possibility that threat actors can already develop an exploit for the vulnerability, another element of concern is that the developers of Linux distributions don’t publish kernel updates very frequently, a circumstance that expose users to attacks.
“However, Linux distributions often don’t publish distribution kernel updates very frequently. For example, Debian stable ships a kernel based on 4.9, but as of 2018-09-26, this kernel was last updated 2018-08-21. Similarly, Ubuntu 16.04 ships a kernel that was last updated 2018-08-27.” Horn explained.
“Android only ships security updates once a month. Therefore, when a security-critical fix is available in an upstream stable kernel, it can still take weeks before the fix is actually available to users – especially if the security impact is not announced publicly.”
This exploit demonstrates the importance of a secure kernel configuration, some specific settings like kernel.dmesg_restrict sysctl provides “a reasonable tradeoff when enabled”.