Linux Kernel Vulnerability and Mitigation

1/23/17

It has been discovered that a Linux kernel race-condition vulnerability can be exploited to allow local privilege escalation if namespaces is enabled (a compile-time kernel option).

Affected systems include:
* RHEL 7 is vulnerable if namespaces has been enabled.  RHEL 5 & 6 are unaffected.
* Debian 7 & 8 are vulnerable if namespaces have been enabled.
* All currently supported versions of Ubuntu appear to be affected. 16.04 is specifically called out in the public announcement as vulnerable by default.

It’s important to note that although many distributions state that they are ‘vulnerable’ this does not necessarily mean they are currently in a state where this vulnerability can be exploited. Many distributions have namespaces disabled by default preventing this vulnerability from being accessed.

To check to see if your Linux system has namespaces enabled you can use the following command as root: sysctl kernel.unprivileged_userns_clone

If the setting is ‘1’, user namespaces is enabled and your system is potentially vulnerable.
If the result is ‘0’ or an error that says the setting does not exist, namespaces is not enabled and your system should not be vulnerable to this exploit.

You can mitigate this issue temporarily by disabling user namespaces. This can be done by disabling the kernel parameter ‘unprivileged_userns_clone’ via the command: sysctl -w kernel.unprivileged_userns_clone=0 Only do this if you are certain that your system does not require user namespaces to be enabled.  For example, it is possible that the use of containers may require associated use of namespaces.  In this case, see recommendations for patching immediately. Alternatively, it is also possible to limit access to this vulnerability on systems using systemd when starting services. Refer to ‘systemd mitigation’ in the References section below.

Mitigation for this vulnerability should only be an interim measure. It’s recommended to patch vulnerable systems within the next maintenance cycle.

References:

The potential impact of any vulnerability, and therefore the appropriate response depends, in part, on operational conditions that are unique to each cyberinfrastructure deployment. The Center for Trustworthy Scientific Cyberinfrastructure (CTSC) cannot provide a one-size-fits-all severity rating and response recommendation for all NSF cyberinfrastructure. Please contact CTSC if you need assistance with assessing the potential impact of this vulnerability in your environment and/or you have additional information about this issue that should be shared with the community.

Contact Us

ScienceGateways.org
A collaboration of seven universities, led by:
San Diego Supercomputer Center
University of California at San Diego
9500 Gilman Drive
La Jolla, CA 92093-0505 USA
858.534.5118
help@sciencegateways.org


This project is funded by the National Science Foundation under award number ACI-1547611. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.