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:
Source-to-Image (S2I) is a tool for building reproducible, Docker-formatted container images. It produces ready-to-run images by injecting application source into a container image and assembling a new image. The new image incorporates the base image (the builder) and built source and is ready to use with the docker run command. S2I supports incremental builds, which re-use previously downloaded dependencies, previously built artifacts, etc.
The flaw is that the paths from a tar archive are used as input to “filepath.Join” without further sanitation. ExtractTarStreamFromTarReader is also used on the client side by “oc rsync”. S2I uses the code to unpack artifacts in its main container.
So if the tar paths are passed to filepath.Join without sanitization, it construct a tar that contains a path like /some/container/../../../../../../tmp/hello.When the function will untar it, it will actually write to /tmp/hello of the host instead of writing to /some/container/tmp/hello.
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:
$ oc adm policy remove-cluster-role-from-group system:build-strategy-source system:authenticated
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 admin
$ 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
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
IAM Roundup: AWS vs. Azure vs. GCPRead the Blog
How to Securely Configure a Linux Host for ContainersRead the Blog
Don’t Forget the Audit Trail! The Role of Reporting in SecurityRead the Blog
Securing Cloud Native Applications on Pivotal Container Service (PKS)Read the Blog
What to Know: Gartner’s Security Considerations and Best Practices for Securing Serverless PaaSRead the Blog