Link An Israeli cybersecurity startup has discovered a zero-day security flaw in the Linux kernel that runs millions of servers, desktops as well as mobile devices that use the Android operating system. An attacker could abuse the flaw to gain root-level privileges on a device and execute arbitrary code or steal any data stored on the device.
See Also: Stop Fraud, Not Customers: Focus On Good User Experience
"The vulnerability is in the core Linux kernel, which is the same on desktops, servers, and Android devices," says Yevgeny Pats, CEO of Perception Point, a security firm founded last year in Tel Aviv that focuses on advanced persistent threat defense. His team believes that the new memory-leak vulnerability, which has been assigned CVE-2016-0728, affects at least 66 percent of all Android mobile devices and tens of millions of Linux PCs and servers. The bug first appeared in 2012 in the Linux kernel version 3.8, and exists on both 32-bit and 64-bit Linux systems.
The discovery of the flaw is bad news for users of older Android operating systems that are no longer being patched - or at least updated in a timely manner - by smartphone manufacturers or their mobile phone operator (see Android Stagefright: Exit Stage Left).
The vulnerability relates to "a problematic flow in a security feature in the Linux kernel" that runs Linux-based desktops and servers, as well as Android devices, Pats says, highlighting the irony of a vulnerability being found in a security feature. "But that happens," he notes. In particular, the flaw exists in the keyrings facility built into the Linux kernel, which provides a way for drivers to retain or cache security-related data, such as authentication keys and encryption keys.
No Attacks Seen in Wild - Yet
Pats says the vulnerability could be exploited via malware to give attackers root-level access to systems. To be clear, however, there is no evidence that hackers have already been exploiting this flaw. But full details were released publicly on Jan. 19, meaning security researchers can now begin looking for any signs of preexisting, in-the-wild exploits. "Maybe they will see that this vulnerability was already used in some other campaigns," Pats says. "Or maybe some old campaigns that weren't detected before, will be detected."
Pats says his company notified the Linux and Red Hat security teams, and that they've prepped related patches, as have some other Linux distributions, such as SUSE Linux Enterprise. "They were very, very responsive, and fixed it quite fast," he says.
Google didn't immediately respond to a query about when the flaw will be patched in the Android code base. As Android is open source, once it gets a related fix, it's then up to phone manufacturers and operating system developers to add the patch to their customized Android distribution and push it to supported subscribers or users. Google itself, meanwhile, issues regular monthly updates and security fixes for its Nexus range of smartphones and tablets, which run a stock version of Android. Google promises to support each particular model it sells for at least two years after the date the device first went on sale in its online store.
Deep Dive: Keyrings
To exploit the newly disclosed flaw, "you have to have local access to the machine," Pats says, or else build malware to gain access to the machine, after which the vulnerability can be exploited to gain root-level access. "Using the API that the kernel provides, you can get root access to the machine."
The vulnerability relates to each Linux process being able to create its own keyring, as well as to optionally assign to it a unique name, according to a related Perception Point technical teardown. If someone tries to replace an existing keyring name with the identical keyring name, it will trigger an error and leak a related number that counts how many times the keyring has been referenced.
An attacker, however, could cause the reference number to rollover back to zero, which makes the kernel think the keyring is no longer needed, thus freeing the object and allowing for a use-after-free attack. By overlaying a new, attacker-controlled keyring over the freed one, plus some savvy programming moves, an attacker could then gain access to the security-related data and gain root-level access to the system.
Pats says that both Supervisor Mode Execution Protection and Supervisor Mode Access Prevention - SMEP and SMAP - on Linux would make exploiting this vulnerability more difficult, though not impossible. So would using the access-control feature known as Security-Enhanced Linux - SELinux - on Android devices, which was added as a feature with Android 4.3 "Jelly Bean," released in July 2013. But as of Jan. 4, Google reports that 27 percent of all in-the-wild Android devices are running version 4.2 of Android or earlier.
Android Versions: Current Distribution
Source: Google (7-day period ending on Jan. 4, 2016)
Android Devices At Risk
News of the vulnerability is a further reminder that older versions of Android should now be considered unsafe. In January 2015, for example, Google reported that for pre-Android 4.4 devices, it would no longer update a crucial component called WebView, which the OS uses to render Web pages (see 930 Million Android Devices at Risk?).
The new vulnerability could be abused by hackers to seize control of unpatched devices. To date, many types of mobile malware have been relatively unsophisticated, often trying to trick users - or install and run mobile ransomware - rather than forcibly taking over their system by exploiting known flaws.
In December, for example, cybersecurity firm FireEye warned that it's found in-the-wild attacks that employ Android malware called SlemBunk. The malware has been targeting users of more than 30 different mobile applications for banks located across North America, Europe and the Asia-Pacific region (see Android Mobile Banking Malware Risk Worsens).
Nevertheless, some types of malware target known vulnerabilities in Android, and most security experts suspect that the sophistication of mobile malware will only continue to increase.
