The new zero-day vulnerability discovered in the Linux kernel highlights the challenges of securing Linux devices that cannot be easily updated. Administrators have access to standard update tools to promptly patch Linux desktops and servers, but a significant segment of Linux devices will remain vulnerable.
The privilege escalation vulnerability allows applications to exploit the kernel as a local user and gain root access, said Yevgeny Pats, co-founder and CEO of Perception Point, which found the vulnerability. It's present in the Linux kernel 3.8 and higher, impacting "tens of millions" of both 32- and 64-bit Linux PCs and servers. Because Android uses the Linux kernel, the vulnerability is also present in all Android devices running KitKat or higher, which accounts for about 66 percent of current users. Linux is also commonly found in embedded systems and the Internet of things, making this a widespread issue.
The vulnerability is related to how kernel drivers use the keyrings facility to save security data, authentication, and encryption in the kernel. Each process can create a keyring for the current session and assign a name. If the process already has a session keyring, the same system call replaces the keyring with a new one. The bug is a reference leak that occurs when a process tries to replace the current session keyring with same keyring. The bug leads into a use-after-free vulnerability when the attacker attempts to access the keyring object and escalate privileges of a local user to gain root access. Because the attacker has elevated privileges, he or she can potentially execute arbitrary code on the targeted machine.
Attackers can potentially exploit the vulnerability, which has been in the kernel since 2012, to perform root-level actions like deleting files, viewing private information, and installing other programs on targeted systems. An attacker would have to get on the targeted machine before being able to trigger the vulnerability (CVE 2016-0728), Pats said. That can be as simple as getting a user to click on a phishing link and download malware.
"While neither us nor the kernel security team have observed any exploit targeting this vulnerability in the wild, we recommend that security teams examine potentially affected devices and implement patches as soon as possible," said Pats.
The kernel team has been notified, and various distributions are expected to be prompt about pushing out the updates, if they haven't already (Red Hat and Ubuntu have already released their updates), and administrators should apply the updates as soon as possible. However, the update may pose some difficulties if the administrator in a container-heavy environment doesn't know what's running inside individual containers.
"Without visibility into what's running in an environment, defense is impossible," said Mike Pittenger, vice-president of strategy at Black Duck Software.
While various Linux distributions can address the vulnerability on Linux desktops and servers through their normal update channels, the fix is more challenging for mobile devices, embedded systems, and IoT devices. The vendor will need to create a patch, then convince the users to apply them through an unfamiliar process. It's not known at this point whether next month's Android update from Google will include the kernel fix, for example.
"Experience tells us that this will leave many systems open to attacks for years to come now that the vulnerability is known," Pittenger said.
Perception Point provided the proof-of-concept for the vulnerability, which runs on 64-bit Linux versions running kernel 3.18 on GitHub. But even with the proof-of-concept available, exploitation is not a done deal. Perception Point noted in its report that Supervisor Mode Access Prevention and Supervisor Mode Execution Protection, two features found on newer Intel CPUs, make it difficult to exploit the vulnerability. SELinux also provides another barrier for Android devices.
Linux in the enterprise isn't only on servers and Android. Administrators should check their containers to see which version of Linux their applications are using, as well as the underlying operating system. It's quite possible the vulnerability may be present in unexpected areas.