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

Public Date: April 24, 2018, 09:20
Updated September 3, 2021, 11:53 - Chinese, Simplified French Japanese Korean
Resolved Status
Critical Impact

Insights vulnerability analysis

View exposed systems

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. 

  

Red Hat customers with affected versions of the ose-sti-builder image in their OpenShift registries are strongly recommended to update them as soon as a newer image is available if disabling source-to-image builds is not an option.  The normal upgrade process is used for versions 3.4 through 3.9.  This involves ensuring the atomic-openshift-utils package is up to date and running the upgrade playbooks:

For clusters running versions 3.1 through 3.3 admins must pull the patched image to all Nodes in the cluster.  If the ‘Diagnose’ steps show you’re using a vulnerable version you can manually update the image by doing the following:

  1. Establish an SSH Connection to each node host
  2. Run `docker pull registry.access.redhat.com/openshift3/ose-sti-builder`
  3. Verify that the pulled image matches the checksum used the ‘Diagnose’ section for the cluster version.

Red Hat would like to stress the importance of updating to the latest Z-stream.  If this is not possible, refer to this KCS for an interim solution.

Note: These images can be tagged to any version number within their same minor patch level.  For example, v3.3.1.36.38 could be tagged to v3.3.1.46.11 if that matched the version of the cluster installed.


Mitigation

Red Hat recommends customers update the software as soon as patches are available.

Customers can turn off the source-to-image (S2I) build strategy to prevent access to the exploitable function.  Information about how to disable the source-to-image build strategy is in the product documentation.

Customers are advised to take a risk-based approach in mitigating this issue.  Systems that require high-degrees of security and trust should be addressed first, and should be isolated from untrusted systems until such time treatments can be applied to those systems to reduce the risk of exploit.


Updates for Affected Products

ProductAdvisory/Update
OpenShift Container Platform 3.9RHSA-2018:1227
OpenShift Container Platform 3.8RHSA-2018:1229
OpenShift Container Platform 3.7RHSA-2018:1231
OpenShift Container Platform 3.6RHSA-2018:1233
OpenShift Container Platform 3.5RHSA-2018:1235
OpenShift Container Platform 3.4RHSA-2018:1237
OpenShift Container Platform 3.3RHSA-2018:1239
OpenShift Container Platform 3.2RHSA-2018:1241
OpenShift Container Platform 3.1RHSA-2018:1243
OpenShift Container Platform 3.0See mitigation above or contact support.

Comments