Bug 1816789 (CVE-2020-10689) - CVE-2020-10689 che: pods in kubernetes cluster can bypass JWT proxy and send unauthenticated requests to workspace pods
Summary: CVE-2020-10689 che: pods in kubernetes cluster can bypass JWT proxy and send ...
Alias: CVE-2020-10689
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On:
Blocks: 1796611
TreeView+ depends on / blocked
Reported: 2020-03-24 18:04 UTC by Marco Benatto
Modified: 2021-02-16 20:23 UTC (History)
1 user (show)

Fixed In Version: Eclipse Che 7.9.0
Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in the Eclipse Che, where it did not properly restrict access to workspace pods. An authenticated user can exploit this flaw to bypass JWT proxy and gain access to the workspace pods of another user. Successful exploitation requires knowledge of the service name and namespace of the target pod.
Clone Of:
Last Closed: 2020-04-14 22:31:48 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2020:1475 0 None None None 2020-04-14 19:27:49 UTC

Description Marco Benatto 2020-03-24 18:04:12 UTC
On Eclipse Che up to version 7.8.x any pod running in a Kubernetes cluster is able to send unauthenticated requests to Eclipse Che Workspaces pods bypassing the JWT proxy. This implies an user can send requests to another user's machine-exec container getting access to it, bypassing the JWT proxy.

For an attack be considered successful, the attacker needs to know the ip or name of targeted service and the namespace where workspaces are running.
This flaw was fixed on Eclipse Che 7.9.0.


Comment 4 Marco Benatto 2020-03-30 20:47:42 UTC

Name: Mario Loriedo (Red Hat)

Comment 6 Marco Benatto 2020-04-01 15:09:05 UTC
Eclipse Che uses JWTProxy to authenticate requests sent among pods from a same workspace, however a flaw was found on the way JWTProxy is used by Eclipse Che it's possible to an attacker interact with theia server from an workspace different than the one he owns. This issue is not trivial to be exploited as the attacker need high privileges in cluster-wide scope and know the IP from the container running the targeted Theia server.

Comment 7 errata-xmlrpc 2020-04-14 19:27:47 UTC
This issue has been addressed in the following products:

  Red Hat CodeReady Workspaces 2.0

Via RHSA-2020:1475 https://access.redhat.com/errata/RHSA-2020:1475

Comment 8 Product Security DevOps Team 2020-04-14 22:31:48 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):


Note You need to log in before you can comment on or make changes to this bug.