Last Friday Michael Hanselmann reported a critical vulnerability to the Red Hat team; the vulnerability affects the the source-to-image build capability that ships with OpenShift 3.x. Permission to use this capability is enabled for any user with the system:authenticated role, which is extended by default to any user who can authenticate to OpenShift. This post will briefly explain the vulnerability, and will be updated accordingly once Michael releases his PoC.
Source-to-image is a tool that enables building Docker container images;
from OpenShift documentation:
The flaw is that the paths from a tar archive are used as input to “filepath.Join” without further sanitation.
So if the tar paths are passed to filepath.Join without sanitization, it construct a tar that contains a path like
In order to construct such tar we can simply edit a tar with a hex editor such as 010editor, as a normal tar utility will not allow us to include backslashes into the tar file.
Armed with a specially crafted tar we can, for example, overwrite ssh keys or write a new init script that will open a remote shell when executed, thus gaining total control on the host.
In order to mitigate the vulnerability you should upgrade your OpenShift deployment, or if that is not an option, simply disable S2I. To do so, login as a user with cluster-admin privileges and issue the following command in order to disable the source-to-image strategy globally in your cluster:
In versions prior to 3.2, the build strategy subresources were included in the admin and edit roles. Ensure the build strategy subresources are also removed from these roles:
$ oc edit clusterrole edit
Protection against this vulnerability with Twistlock
Of course, Twistlock can help protect you from vulnerabilities like this, with multiple layers of defense in depth. First, Twistlock identifies the vulnerable OpenShift components across your environment:
In addition to vulnerability awareness, you can also use granular rules to prevent vulnerable images from being started after you’ve upgraded the environment. Finally, and most powerfully, our runtime defense capability learns normal app behaviors and prevents writes to unexpected file system paths.
Thanks for reading and don’t forget to follow us @TwistlockLabs.
Follow us on Twitter
Keep up to date with the latest news from TwistlockLabs and TwistlockTeam.
6 Tips for Secure Data Management for Containers
One of the main reasons why containers have become so popular is that ...
OpenShift Internal Registry: Populating Registry Scans with Twistlock
Twistlock uses the Docker v2 Registry catalog API call to inventory im...
Better Together: Protecting Docker Registries with Twistlock and JFrog Artifactory
In a containerized devops lifecycle, a registry such as JFrog Artifact...
Support for Emerging Container Runtimes: RunC, containerd, cri-o and Beyond
In the beginning there was lxc… or maybe Solaris Zones, or BSD J...
Twistlock Jenkins Plugin and Time-Based Vulnerability Blocking : 2.4 Deep Dive
Twistlock has provided the ability to seamlessly integrate security in...