`OpenShift` allows a user to create his own images with the help of the build component. This component has three primary build strategies available ([Docu - Understanding image builds](https://docs.openshift.com/container-platform/4.16/cicd/builds/understanding-image-builds.html)):

* Docker build
* Source-to-Image (S2I) build
* Custom build

As the builds are running in a privileged container, a vulnerability in this process allows an attacker to escalate their permissions on the cluster and host nodes.

The `custom build` is not safe, because they can execute any code within a privileged container and are disabled by default.
The other two strategies are considered as safe and are enabled for all users that can create builds. 

But there is a note about the `docker strategy`:

>  Grant docker build permissions with caution, because a vulnerability in the Dockerfile processing logic could result in a privileges being granted on the host node.

See: https://docs.openshift.com/container-platform/4.16/cicd/builds/securing-builds-by-strategy.html


The `docker strategy` / the image used during the build has a vulnerability, which allows an attacker to override files inside the privileged build container with the help of the `spec.source.secrets.secret.destinationDir` attribute of the `BuildConfig` definition. After overriding the binary, execution of this overriden file can be triggered with another secret and the malicious code is executed in the privileged container.  

As stated above, running code in a privileged container allows an attacker to escalate their permissions on the cluster and host nodes. As an example the host filesystem of the worker node can be mounted and a new `SSH` key can be added to user `core` of the `Red Hat Enterprise Linux CoreOS (RHCOS)`.