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_
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.
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.