RHSB-2021-004 Symlink-Exchange attack - runc - (CVE-2021-30465)

Executive summary

Red Hat is aware of a flaw found in runc where an attacker who can deploy a container could potentially escape from the container to the host system. This issue has been assigned CVE-2021-30465 and has been rated with a severity impact of Important. If SELinux is running in enforcing mode, the impact is reduced.

The following Red Hat product versions are directly affected:

• Red Hat Enterprise Linux 8

• Red Hat OpenShift Container Platform 4.x

• Red Hat Enterprise Linux 7

• Red Hat OpenShift Container Platform 3.x

Further, any Red Hat product supported on the Red Hat Enterprise Linux platform is also potentially impacted. This includes products that pull packages from the RHEL channel.  Please ensure that the underlying Red Hat Enterprise Linux runc or docker package is current in these product environments.

To determine if your system is currently vulnerable to this flaw, see the Diagnose section below.

Technical summary

A vulnerability discovered in runc allows for a break out from the container and gains access to the host filesystem.

This vulnerability affects runc and all its dependent container tools packages available on Red Hat Enterprise Linux (RHEL) 8. OpenShift Container Platform (OCP) 4.x is also affected as it also uses runc via cri-o.

This vulnerability affects both the docker and runc packages available on Red Hat Enterprise Linux 7, which are delivered through the Extras channel. OpenShift Container Platform (OCP) 3.x depends on these packages from Red Hat Enterprise Linux 7 Extras and is also affected.

Mitigation

The impact of the vulnerability is reduced if SELinux is in enforcing mode using the container-selinux policy. The container-selinux policy is installed and enabled by default on RHEL 7 and 8, as well as OpenShift Container Platform 3.x and 4.x.

Customers running affected versions of RHEL are strongly recommended to apply RPM updates from the RHEL 8 channel and RHEL 7 Extras channel as soon as errata becomes available.  

Customers running affected versions of OpenShift Container Platform are strongly recommended to upgrade as soon as errata becomes available.

Customers of OpenShift Dedicated and Azure Red Hat OpenShift have SELinux enabled in enforcing mode in every host across all clusters. Therefore, It is expected that OSD/ARO both have a reduced impact from this issue, with security patches made available during upcoming maintenance windows.

Technical details

The runc package is vulnerable to a symlink exchange attack whereby an attacker can request a seemingly innocuous container configuration that results in the host filesystem being bind-mounted into the container.

The runc package can be used standalone to run containers, however it is usually used by other packages to run containers. On RHEL 8, the container-tools module package, podman, uses runc and is therefore vulnerable via its dependency on runc.  OCP 4 is vulnerable via the cri-o package, which uses runc. On RHEL-7, the docker package embeds runc and is vulnerable to this issue. OCP 3 uses the docker package in its default configuration and is also affected. OCP 3 can be configured to use cri-o instead of docker, and in that case, is affected as well.

In circumstances where a container is being started, and runc is mounting inside a volume shared with another container (which is conducting a symlink-exchange attack), runc can be tricked into mounting outside of the container root filesystem by swapping the target of a mount with a symlink due to a time-of-check-to-time-of-use (TOCTTOU) flaw.

However, this alone is not useful because this happens inside a mount namespace with "MS_SLAVE" propagation applied to "/" (meaning that the mount doesn't appear on the host -- it's only a "host-side mount" inside the container's namespace). To exploit this, you must have additional mount entries in the configuration that use some subpath of the mounted-over host path as a source for a subsequent mount.

Product impact

OpenShift Container Platform

In the case of OpenShift Container Platform, this issue is exploitable by creating a symlink in a volume to the top-level (well-known) directory where volumes are sourced from (for instance, "/var/lib/kubelet/pods/$MY_POD_UID/volumes/kubernetes.io~empty-dir"), and then using that symlink as the target of a mount. 

The source of the mount is an attacker-controlled directory, and thus the source directory from which subsequent mounts will occur is an attacker-controlled directory. The attacker can first place a symlink to "/" in their malicious source directory with the name of a volume, and a subsequent mount in the container will bind-mount "/" into the container.

The impact of the vulnerability is reduced if SELinux is in enforcing mode using the container-selinux policy. The container-selinux policy is installed and enabled by default on OpenShift Container Platform 3.x and 4.x.

Service impact

OpenShift Dedicated and Azure Red Hat OpenShift

In OpenShift Dedicated (OSD) and Azure Red Hat OpenShift (ARO)  each customer has one or more dedicated clusters and does not share these clusters.  As a result, exposure is limited to only that  customer.

OpenShift Dedicated and Azure Red Hat OpenShift customers have SELinux enabled in enforcing mode in every host across all clusters, which reduces the impact (more details on the FAQ below).

This vulnerability can be exploited only if an attacker is able to deploy a container. Deploying containers in OSD/ARO is only possible for authenticated and authorized users.  Red Hat recommends that only trusted containers are deployed (ex. verify that they come from a trusted source, Health Index is ok [6])

Red Hat Developer Sandbox

The vulnerable package is present in the Red Hat Developer Sandbox as a transitive dependency of another package. It is neither used nor needed, and the service is not affected. In any case, during an upcoming maintenance window, the package is removed.

Red Hat OpenShift API Management

The vulnerable package is present in the Red Hat OpenShift API Management code base. Only administrators of the managed service can deploy containers, which are verified and trusted before deployment. The service has not been affected and the risk is low. In any case, during an upcoming maintenance window, the vulnerable package is upgraded. 

Updates for affected products

Red Hat customers running affected versions of these Red Hat products are strongly recommended to update as soon as erratas are available. Customers are urged to apply the available updates immediately or enable the mitigations as they feel appropriate.  

[1] Advisory/Update link will be added once updates are live.

[2] What is the Red Hat Enterprise Linux Extended Update Support (EUS) Subscription?

[3] What is Advanced mission critical Update Support (AUS)?

[4] What is the Red Hat Enterprise Linux SAP Solutions subscription?

[5] An active Extended Life-cycle Support (ELS) subscription is required for access to this patch.  Please contact Red Hat sales or your specific sales representative for more information if your account does not have an active ELS subscription.

[6] Product containers which use the Red Hat Enterprise Linux base image. Base images will be updated to include fixes for this flaw, please ensure containers are current. The Container Health Index, part of the Red Hat Container Catalog, can be used to verify the security status of Red Hat containers.

[7] Products which pull packages from the RHEL channel.  Please ensure that the underlying Red Hat Enterprise Linux runc or docker package is current in these product environments

Diagnose

A vulnerability detection script has been developed to determine if your system is currently vulnerable to this flaw. To verify the authenticity of the script, you can download the detached GPG signature as well. Instructions on how to use GPG signature for verification are available on the Customer Portal.

FAQ

Q: Does SELinux mitigate this vulnerability?

A: While it’s still possible to exploit the vulnerability when SELinux is in enforcing mode the impact of the vulnerability is reduced. An attacker would have the host file system mounted in a container process with an SELinux label. SELinux prevents you from getting access to files or sockets which aren't allowed by your label. It may still be possible to leverage the vulnerability to have some impact on confidentiality, integrity or availability of the host operating system.

Q: What is the likelihood of this vulnerability being exploited?

A: If you allow untrusted users to run containers in your environment or allow trusted users to deploy untrusted containers in your environment, then you are more likely to be impacted by this issue.

Acknowledgements

Red Hat thanks the upstream Open Containers Security Team for reporting this issue. Upstream acknowledges Etienne Champetier as the researcher who discovered this flaw.

References

• https://github.com/opencontainers/runc/security/advisories/GHSA-c3xm-pvg7-gh7r
• How to use GPG to verify signed content from Product Security