OpenShift Source-To-Image Vulnerability - CVE-2018-1102

Red Hat Product Security is responding to a flaw in the source-to-image (S2I) build functionality as shipped with Red Hat OpenShift Container Platform 3. Unprivileged attackers can use this flaw to escalate privileges and gain access to the host system. This issue has been assigned CVE-2018-1102 and is rated as having a Critical impact.

Background Information

This issue affects the source-to-image build strategy. Permission to use this strategy is enabled for any user with the system:authenticated role which is extended by default to any user who can authenticate to OpenShift.

This issue was reported directly to Red Hat by Michael Hanselmann.

Vulnerability Details

By creating a maliciously formatted tar archive, an attacker can abuse the untar functionality in S2I during a build and escalate privileges resulting in compromise of the underlying host operating system running OpenShift.

Take Action

See the Impact tab for affected Red Hat Products and the Resolve tab for mitigation and update information.

Impacted Products

Red Hat Product Security has rated this update as having a security impact of Critical.  An attacker can remotely leverage this vulnerability to get root permissions on an OpenShift Node.

The following Red Hat Product versions are impacted:

• OpenShift Container Platform 3.0-3.9
• OpenShift Online v3.x*
• OpenShift Dedicated v3.x*

*Red Hat has patched impacted services.  

Diagnose Your Vulnerability

There is no known proven or consistent way to detect when a malicious actor has privileged access to the system.  Red Hat recommends good security practices and for customers to take a risk-based approach to system and log monitoring to detect evidence of potential misuse.  To determine if a cluster is vulnerable, check the version of the atomic-openshift package running on the masters.  That service controls the code that determines the source-to-image build image in use.  For each minor release of OpenShift, Masters running these versions or later have been patched:

• 3.9: atomic-openshift-3.9.25-1.git.0.6bc473e.el7
• 3.8: atomic-openshift-3.8.37-1.git.0.e85a326.el7
• 3.7: atomic-openshift-3.7.44-1.git.0.6b061d4.el7
• 3.6: atomic-openshift-3.6.173.0.113-1.git.0.65fb9fb.el7
• 3.5: atomic-openshift-3.5.5.31.67-1.git.0.0a8cf24.el7
• 3.4: atomic-openshift-3.4.1.44.53-1.git.0.d7eb028.el7

For versions 3.1 through 3.3 additional steps are needed.   On every OpenShift Node host run:

`$sudo docker images | grep ose-sti-builder`
registry.access.redhat.com/openshift3/ose-sti-builder       v3.3.46.38      cee523a4e55c   2 weeks ago     608 MB

In this example cee523a4e55c represents an unpatched image.  Since these images will have the same version number as the last release it’s important to check the sha256 sum.  The patched images with their corresponding checksums are:

• 3.3:  registry.access.redhat.com/openshift3/ose-sti-builder:v3.3.1.46.39 (b285a30ab8e0)
• 3.2:  registry.access.redhat.com/openshift3/ose-sti-builder:v3.2.1.34 (b536950df3d8)
• 3.1: registry.access.redhat.com/openshift3/ose-sti-builder:v3.1.1.11 (de9eb6fe3b01)

If the unpatched image can be deleted, do so as this will cause a fresh (patched) copy to be downloaded the next time it’s needed:

$ sudo docker rmi cee523a4e55c

Note: The checksum can differ from what is listed above, but the value to be used here is collected from: `sudo docker images | grep ose-sti-builder`

This may fail for a number of reasons, including “image is in use by stopped container xyz”.  In this case, we add a second (arbitrary) tag to the image so that the version tag can subsequently be removed without error.  The result, again, is for a fresh (patched) copy to be downloaded to this node the next time it’s needed.

$ BADIMAGE=cee523a4e55c
$ BADVERS=v3.3.46.38
$ sudo docker tag $BADIMAGE    registry.access.redhat.com/openshift3/ose-sti-builder:donotuse
$ sudo docker rmi registry.access.redhat.com/openshift3/ose-sti-builder:$BADVERS

Detection Script

Determine if your system is vulnerable. Use the detection script to determine if your system is currently vulnerable to this flaw. To verify the legitimacy of the script, you can download the detached GPG signature as well.