Bug 2163586 (CVE-2023-0456)

Summary:	CVE-2023-0456 APICast: APICast proxies the API call with incorrect JWT token to the API backend without proper authorization check
Product:	[Other] Security Response	Reporter:	Paramvir jindal <pjindal>
Component:	vulnerability	Assignee:	Nobody <nobody>
Status:	NEW ---	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	unspecified	CC:	amackenz, amasferr, chazlett, m3d5ec, mkudlej, tjochec
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	apicast 2.12.2, apicast 2.13.2, apicast 2.14.0	Doc Type:	If docs needed, set a value
Doc Text:	A flaw was found in APICast, when 3Scale's OIDC module does not properly evaluate the response to a mismatched token from a separate realm. This could allow a separate realm to be accessible to an attacker, permitting access to unauthorized information.	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:	2163584

Description Paramvir jindal 2023-01-24 00:37:39 UTC

https://issues.redhat.com/browse/THREESCALE-9009

Steps to reproduce

    Deploy 3scale + APIcast 2.12
    Configure a single Product A with an OpenID Provider + realm A
    Generate a token on the OpenID Provider but a different realm with a client not subscribed to Product A
    Set the backend with a Public Path != "/" (setting a value here is important to enable the routing policy)
    Send a request to the gateway using Host & path that will match Product A

The above conditions will trigger the 404 Not Found returned to APIcast by backend and also the proxy pass to the upstream which results in the upstream response being sent back to the client.
Observations

    The oidc module is not catching an exception when the JWK cannot be found due to the fact the JWT contains a mismatching kid.
    The failure to catch this exception then results in a further failure within the proxy module which should be able to evaluate the object returned by the oidc module and fail the authorisation logic but instead it continues to the authrep but without the required parameters which results in an incomplete request sent to backend and thus the 404 Not Found.
    Furthermore if the routing policy is enabled then it seems that as the proxy module has evaluated- incorrectly - that the JWT is already cached then it is able to send the request to the upstream. This doesn't happen without the routing policy because for some unknown reason as of yet the upstream is logged as being invalid otherwise it would also result in the proxy pass happening.