CVE-2016-0728: Evaluating the Threat Level

On January 14, 2016 researchers at Perception Point identified a 0-day local privilege escalation vulnerability (CVE-2016-0728) in Linux Kernel versions 3.8 to 4.4 (2012 – 2016). This flaw exists due to the kernel’s keyrings security facility used to retain cached security data, authentication keys, encryption keys and other data. Using a local user account, one can free a referenced keyring object and overwrite it to be executed in the kernel, escalating privileges to root. Based on statistics provided by Perception Point, tens of millions of personal computers (PCs), servers and 66% of all Android devices may be vulnerable.

NTT Security reviewed the publication provided by Perception Point and conducted further research into the exploit. Our findings suggested the media failed to address key facts before publishing articles, causing panic throughout the Linux community. Although NTT Security agrees to the vulnerability’s seriousness, complexity and consistent roadblocks during exploit attempts suggest there will be few to no exploits in the wild by threat actors. If they occur, these attempts may be opportunistic after compromising a local account, but should prove to be challenging for the attacker.

Technical Analysis

NTT Security technical analysis provides insight into the complexity of this exploit, in conjunction with multiple avenues used. This analysis is not meant to break down the entire vulnerability and exploit as provided by Perception Point.

Accessing the Keyrings Facility

In order to access the keyrings, the keyutils.h header file is required in the Point-of-Compromise (PoC) code (cve_2016_0728.c). This header file is not installed by default on most Linux systems. Sure, the attacker could just install the libkeyutils-dev package, but this requires root privileges. If we have these privileges it defeats the purpose anyway, right?

Figure 1: Header file code

Figure 1: Header file code

Elevating Privileges Using a Precompiled Binary?

So maybe the attacker wants to elevate privileges on a machine on which they do not have sudo or root permissions. The attacker could precompile a binary on a system they control so it includes the necessary libraries and move it to the target machine right?  Review of the PoC code indicates that for the exploit to work the variables below have to be defined first. These will be different across Linux distributions (distros) and kernel versions, so the correct address for the target server will need to be obtained before compiling the binary.

#define COMMIT_CREDS_ADDR (0xffffffff81094250)

#define PREPARE_KERNEL_CREDS_ADDR (0xffffffff81094550)

Below are examples of addresses, showing their difference based on kernel versions.

Figure 2: Address examples

As you can see, the addresses vary based on kernel versions as well as the distro. Also, it should be noted that root access is required to get the correct addresses, as shown below.

Figure 3: Code depicting root access requirement

What about Android Devices?

While it is true Android devices with these kernel versions are vulnerable, the complexity of the attack still remains. On January 20, 2016 Adrian Ludwig, Android's lead security engineer, wrote a blog announcing a patch for Android devices will be released to open source and provided to cellular providers. The patch is required on all devices with a security patch level of March 1, 2016 or greater. Adrian Ludwig also explained, “…that the number of Android devices affected is significantly smaller than initially reported“ and “devices with Android 5.0 and above are protected, as the Android SELinux policy prevents 3rd party applications from reaching the affected code.” Last but not least, he explained “…devices running Android 4.4 and earlier do not contain the vulnerable code introduced in Linux kernel 3.8, as those newer kernel versions [are] not common on older Android devices.”

Common Vulnerability Scoring System (CVSS) Score

The National Vulnerability Database (NVB) was analyzing this vulnerability at the time of this writing so no official CVSS score is available, but using the provided calculator, NTT Security determined an unsurprising CVSS score of 5.0. Of course, NTT Security cannot guarantee this will be the official score, as it is still rather low.

Figure 4: CVSS Score (screenshot)


Final Thoughts

Although the media seems to be going a little crazy over this vulnerability, its complexity makes the exploit fairly difficult. NTT Security considered numerous possible scenarios where an attacker may use different avenues during the intrusion; however, each suggested the local user would already have root access to gain information about the system or would have to possess a detailed understanding of the target host to set up the PoC code properly, defeating the purpose.

Although there may be millions of devices vulnerable, such as PCs, servers, and Internet-of-Things (IoT) devices, NTT Security has classified this vulnerability as a low level threat

If you own a vulnerable device, simply apply the patch and carry on. When applying patches, please keep the following in mind:

  • Kernel patches are not automatic, so ensure you reboot after applying the patch.
  • Installations for all other patches are not automatic by default. Patches are typically set to download and prompt by default, unless configured to install automatically and reboot.