Bug 2188607 (CVE-2023-2250)

Summary:	CVE-2023-2250 MCE: Potential Cluster Level Privilege Escalation In Open Cluster Management
Product:	[Other] Security Response	Reporter:	Borja Tarraso <btarraso>
Component:	vulnerability	Assignee:	Nobody <nobody>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	gparvin, jqiu, njean, owatkins, pahickey, stcannon, teagle
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	mce 2.3.0	Doc Type:	If docs needed, set a value
Doc Text:	A flaw was found in the Open Cluster Management (OCM) when a user has access to the worker nodes, which contain the cluster-manager-registration-controller or cluster-manager deployments. This flaw allows a malicious user to bind the cluster-admin to any service account or use the service account to list all secrets for all Kubernetes namespaces, leading to a cluster-level privilege escalation.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2185641

Description Borja Tarraso 2023-04-21 11:13:43 UTC

The Open Cluster Management (OCM) has a deployment called "cluster-manager-registration-controller" inside the "open-cluster-management-hub" namespace, which runs on a worker node randomly and has a service account called cluster-manager-registration-controller-sa. This service account has a ClusterRole called open-cluster-management:cluster-manager-registration:controller via ClusterRoleBinding. The cluster role has "get list watch create update patch delete escalate bind" verbs of the "clusterroles.rbac.authorization.k8s.io" resources, and has "get list watch create update patch delete" verbs of the "clusterrolebindings.rbac.authorization.k8s.io".

The Open Cluster Management (OCM) has another deployment called "cluster-manager" inside the "open-cluster-management" Kubernetes namespace, which runs on worker nodes randomly and has a service account called cluster-manager, which has a cluster role called "cluster-manager" via cluster role binding. The cluster role has "get list" verbs of the "secret" resources, has "create get list update watch patch delete escalate bind" verbs of the "clusterroles.rbac.authorization.k8s.io", and has "create get list update watch patch delete" verbs of "clusterrolebindings.rbac.authorization.k8s.io" resources.

Thus, if the malicious user can access the worker node which has one of this two deployments, it can leverage the service account to:

1. Bind the cluster-admin to any service account token, resulting in cluster-level privilege escalation.
2. Using the service account of cluster-manger to list all secrets in ALL kubernetes namespaces (i.e., the cluster's admin secret if created), resulting in cluster-level privilege escalation.