Bug 2260372 (CVE-2024-25133)

Description:
Hive uses the ClusterDeployment.hive.openshift.io resource to allow users,
including users with developer roles, to bootstrap a new hosted OpenShift
cluster. The configuration to communicate with those clusters, and linked
infrastructure, is stored in Secrets referenced by the ClusterDeployment
resources.

AWS credentials file have a credentials_process configuration primitive
allowing to retrieve the AWS authentication tokens. The Kubernetes client
have a similar configuration primitive: users[].user.exec

The Hive controllers will, depending on user-controlled configuration for
ClusterDeployments, try to contact AWS for setting up AWS PrivateLink
and/or try to communicate with the remote cluster using the Kubernetes
client. When trying to obtain a client for either of these, the command
provided by the user in the AWS credentials or Kubernetes client
configuration will be executed by the hive/hive-controllers pod under a
privileged service account.

This finding makes use of inherent capabilities of AWS and Kubernetes
clients.

Note: the testing cluster was not configured for supporting AWS
PrivateLink. Fake values were inserted in the HiveConfig to showcase the
vulnerability.

Impact:
A developer account on a Hive-enabled cluster can obtain cluster-admin
privileges by executing arbitrary commands on the hive/hive-controllers pod.
Recommendations

Because this vulnerability arises from inherent capabilities of AWS and
Kubernetes client configurations, a first operational measure would be to
gate-keep access to it. RBAC should be configured to only allow users
belonging to cluster-admin to create ClusterDeployment.hive.openshift.io
resources. If, for practical reasons, RBAC is to be relaxed on this
resource for users in the dedicated-admin group, those users would be able
to perform the same privilege escalation described here.

In parallel, the possibility of removing the “command execution by design”
from configuration files should be explored. This could be through cloning
the vendored dependencies and removing support for this dangerous feature,
or by proposing a merge request to the upstream dependency to ensure a
safe-mode is possible and risks are well documented.

References:
https://kubernetes.io/docs/reference/config-api/kubeconfig.v1/#ExecConfig
https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sourcing-external.html