The MustGather.managed.openshift.io Custom Defined Resource (CRD) is
intended to be used to collect information on the cluster to assist in a
support case. The normal procedure for using this resource is to have a
cluster administrator create such a resource, which will in turn launch a
Job in the openshift-must-gather-operator namespace to perform the
collection and upload.

However, no permissions are defined to access the MustGather CRD,
developer-privileged accounts can, by using F-02 Bypass in Managed
Resources Admission Webhook, create such resources.

The definition of the collection Job is created through a yaml text
template evaluated using user-controlled inputs from the MustGather’s spec.
Furthermore, user-controlled inputs are not sanitized or otherwise
verified. This results in a template injection primitive, with the Job’s
yaml definition being almost fully controlled by user inputs (truncation is
also possible):

* controllers/mustgather/mustgather_controller.go Template evaluation

* controllers/mustgather/mustgather_controller.go Template initialization

* build/templates/job.template.yaml Template

Also, the MustGather CRD allows specifying the desired service account for
the Job, all collection operations are therefore performed under the
service account’s identity. One of the two service accounts in the
openshift-must-gather-operator is a cluster administrator.

Chaining the properties described above, a standard developer with no
privileged permissions on the cluster can create a MustGather object with
specially crafted contents (under spec) and set the most privileged service
account to run the Job. When the Job runs, the crafted contents will tamper
with the templated bash command in the Job’s definition to execute
arbitrary commands on the Job’s Pod. Thanks to the service account supplied
in the MustGather object, a token with cluster-admin privileges will be
present on the Job’s Pod.
Impact

An attacker with a standard developer account can elevate his privileges to
cluster administrator. From a cluster administrator privilege, the attacker
can also read the kube-system/osdManage secret and pivot to the AWS
environment with administrator privileges, see F-03 osdManagedAdmin Has
Redundant and High privileges on AWS Account.
Recommendations

Fixing this issue will require the following:

* Only allow MustGather objects to be created by users with the
cluster-admin role.

* Replace the Job definition template by a construction of Go structs.

* Validate user inputs to build the Job definition are in the expected
format.

* (If possible) Remove or strip permissions to the minimal required for
system:serviceaccount:openshift-must-gather-operator:must-gather-admin