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.
AWS Fargate 101
AWS Fargate is one of the newest services in the world of containers. ...
Security Alert: ESlint Malicious Packages Insights
On July 12, 2018, the ESLint project experienced a security incident, ...
Serverless Comparison: Lambda vs. Azure vs. GCP vs. OpenWhisk
Serverless computing adoption is growing at exponential rates. As with...
4 Steps to Jumpstart your DevSecOps Practices
If you understand DevOps, you probably also intuitively understand Dev...
Squaring the Circle: Making CI/CD Fast and Secure
Today, most DevOps teams place priorities on software delivery speed a...