Bug 2239517 (CVE-2023-5056)

Summary:	CVE-2023-5056 skupper-operator: privelege escalation via config map
Product:	[Other] Security Response	Reporter:	Chess Hazlett <chazlett>
Component:	vulnerability	Assignee:	Product Security <prodsec-ir-bot>
Status:	NEW ---	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	unspecified	CC:	ansmith, chazlett, mcressma, pjindal, saroy, security-response-team
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:	A flaw was found in the Skupper operator, which may permit a certain configuration to create a service account that would allow an authenticated attacker in the adjacent cluster to view deployments in all namespaces in the cluster. This issue permits unauthorized viewing of information outside of the user's purview.	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:	2238780

Description Chess Hazlett 2023-09-18 18:43:11 UTC

The latest skupper operator allows privilege escalation on a kubernetes cluster. If the skupper operator is running and a user in a given namespace creates a ConfigMap with the name skupper-site and includes in the data the line, `cluster-permissions: "true"`, then the operator will  create a service account in that namespace that has cluster permissions enabling it to watch deployments in all namespaces on the cluster. This is the case even if the user creating that ConfigMap does not themselves have access to other namespaces.

The solution we propose is to make this feature optional at the operator level, and off by default. We have a patch ready for this (it has not been shared outside relevant Red Hat engineers) but want to be sure we follow the correct process.

Comment 3 errata-xmlrpc 2023-10-31 18:04:49 UTC

This issue has been addressed in the following products:

  Service Interconnect 1 for RHEL 9

Via RHSA-2023:6219 https://access.redhat.com/errata/RHSA-2023:6219