A container on-entry vulnerability was found in docker and has been assigned CVE-2016-9962. The flaw addresses a specific attack that uses
ptrace and improperly-flushed file descriptors to gain access to content outside a container. This attack is only a risk when running privileged containers and is mitigated by SELinux.
This issue was publicly disclosed on January 10, 2017.
This vulnerability arises when a process that would normally run in one namespace is launched or moved into a different namespace. Namespaces normally act as a security mechanism because processes within different namespaces cannot see or manipulate one another. The problem is that when a process is moved into a namespace, it becomes exposed to malicious actions from processes that are already in that namespace. On-entry vulnerabilities attack processes that join containers via
docker exec . A successful attack can result in a malicious process gaining system access or other privileges.
For example, if a malicious process has taken over a container and managed to obtain
root within that container, the malicious process can kill any other process it can "see". Fortunately, container namespacing keeps the malicious process from being able to detect or kill any host processes or any of the processes in other containers. However, if an administrator attempts to investigate the issue by using
nsenter to move a shell into the misbehaving container, the malicious process can see and manipulate that shell as well (and terminate it).
Vulnerable Linux Facilities
The following legitimate Linux facilities can be misused in on-entry attacks. Use Linux security mechanisms such as
seccomp to prevent their exploitation.
"Process trace" or
ptraceis a powerful debugging facility that is available in Linux. Any process with adequate permissions can
ptraceanother process through the
ptracegrants extremely low-level access to the process, including its memory, resources (such as file descriptors), and the ability to intercept process kernel calls.
- docker exec
docker execis a service provided by the docker daemon that allows an additional process to be launched within an existing container. This is often used to inspect or make manual changes to the container. For example, to launch a bash shell within a misbehaving container in order to debug its behavior, you could use:
docker exec -it container-name /bin/bash
nsenteris a Linux utility used to move or launch processes within specific namespaces. Because containers are built on Linux namespaces,
nsentercan be used as a more generic version of
- kernel capabilities
In Linux, the special powers traditionally granted to the
rootaccount have been split into individual capabilities, and some grant more than one administrative power. For example,
CAP_SYS_TIMEgrants only the ability to set the system clock.
CAP_SYS_ADMIN, on the other hand, grants the range of powers needed to administer a machine. Each kernel capability can be granted or denied to a process individually.
seccompLinux facility allows access to kernel calls on an individual basis.
Red Hat Product Security has rated this update as having a security impact of Moderate .
The following Red Hat Product versions are impacted:
- Red Hat Enterprise Linux 7
- Red Hat Openshift Container Platform
- RHEL Atomic Host
The flaw in CVE-2016-9962 occurs because a safety mechanism is missing from
docker exec .
Until upstream docker 1.12.6, processes that
docker exec launched could be
ptrace 'd within the container and they briefly kept their file descriptors, which were linked to content outside the container. This could be exploited by a process within a container equipped with
ptrace abilities. If a malicious process acted quickly enough, it could
ptrace the incoming process and gain access to content outside the container. This has been addressed in docker 1.12.6 by preventing `ptrace`ing of these processes (through the
DUMPABLE process attribute) and by having incoming processes flush their file descriptors before being moved.
Even without the backport, most installations are not at risk:
- The docker runtime strips containers of many kernel capabilities by default, including
CAP_SYS_PTRACE. This means that only containers for which this capability has been explicitly added (or which are running with the
--privilegedswitch) pose a risk. Moreover, only privileged processes within those containers pose a risk. Unprivileged user processes within those containers do not have sufficient powers to cause harm. Therefore, if you are following the recommended container practices of “not running privileged containers” and “not running root processes within containers”, you are safe.
- On Red Hat systems with SELinux enabled, the dangers of even privileged containers are mitigated. SELinux prevents container processes from accessing host content even if those container processes manage to gain access to the actual file descriptors.
- In most installations,
docker execare purely manual operations. OpenShift uses
nsenterto facilitate port-forwarding, but without manual intervention, vanilla docker will never move a process into a container or between containers.
Diagnose your vulnerability
All Red Hat customers running the affected versions of docker are recommended to update when patches are available. Details about impacted packages as well as recommended mitigation are noted below.
Updates for Affected Products
|Red Hat Enterprise Linux 7||docker-latest, docker, runc||RHSA-2017-0116 , RHSA-2017-0123 , RHSA-2017-0127|
|Red Hat Openshift Container Host||docker-latest, docker||patch applied|
|RHEL Atomic Host||docker-latest, docker, runc||patch applied|
ptrace and other dangerous kernel calls can be banned from your containers. Custom seccomp profiles can be created to forbid this behaviour (supported by vanilla docker, OpenShift, and Kubernetes). This will completely prevent attacks based on CVE-2016-9962.
Subscriber exclusive content
A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.