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.
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.
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.
See the Impact tab for affected Red Hat Products and the Resolve tab for mitigation and update information.
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-184.108.40.206.113-1.git.0.65fb9fb.el7
- 3.5: atomic-openshift-220.127.116.11.67-1.git.0.0a8cf24.el7
- 3.4: atomic-openshift-18.104.22.168.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 v22.214.171.124 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:v126.96.36.199.39 (b285a30ab8e0)
- 3.2: registry.access.redhat.com/openshift3/ose-sti-builder:v188.8.131.52 (b536950df3d8)
- 3.1: registry.access.redhat.com/openshift3/ose-sti-builder:v184.108.40.206 (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.
$ 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
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:
- OpenShift Container Platform 3.4 - Performing Automated In-Place Cluster Upgrades
- OpenShift Container Platform 3.5 - Performing Automated In-Place Cluster Upgrades
- OpenShift Container Platform 3.6 - Performing Automated In-Place Cluster Upgrades
- OpenShift Container Platform 3.7 - Performing Automated In-Place Cluster Upgrades
- OpenShift Container Platform 3.9 - Performing Automated In-Place Cluster Upgrades
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:
- Establish an SSH Connection to each node host
- Run `docker pull registry.access.redhat.com/openshift3/ose-sti-builder`
- 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, v220.127.116.11.38 could be tagged to v18.104.22.168.11 if that matched the version of the cluster installed.
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.
- Disabling S2I in OpenShift Enterprise 3.0
- Disabling S2I in OpenShift Enterprise 3.1
- Disabling S2I in OpenShift Enterprise 3.2
- Disabling S2I in OpenShift Enterprise 3.3
- Disabling S2I in OpenShift Enterprise 3.4
- Disabling S2I in OpenShift Enterprise 3.5
- Disabling S2I in OpenShift Enterprise 3.6
- Disabling S2I in OpenShift Enterprise 3.7
- OpenShift Enterprise 3.8 is not a production version (only for upgrades).
- Disabling S2I in OpenShift Enterprise 3.9
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
|OpenShift Container Platform 3.9||RHSA-2018:1227|
|OpenShift Container Platform 3.8||RHSA-2018:1229|
|OpenShift Container Platform 3.7||RHSA-2018:1231|
|OpenShift Container Platform 3.6||RHSA-2018:1233|
|OpenShift Container Platform 3.5||RHSA-2018:1235|
|OpenShift Container Platform 3.4||RHSA-2018:1237|
|OpenShift Container Platform 3.3||RHSA-2018:1239|
|OpenShift Container Platform 3.2||RHSA-2018:1241|
|OpenShift Container Platform 3.1||RHSA-2018:1243|
|OpenShift Container Platform 3.0||See mitigation above or contact support.|
Subscriber exclusive content
A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.