Community
Participate
Working Groups
Created attachment 280082 [details] POC It is currently possible to create and launch arbitrary containers from a remote website on the same machine that is running Che in standalone mode. This bug can be duplicated by first following these instructions for Single-User mode: https://www.eclipse.org/che/docs/che-6/quick-start.html After Che is started and accessible on port 8080, a victim only needs to visit a malicious website that can POST to Che. I have a demonstration video here: https://www.youtube.com/watch?v=0e3ZFE5W6IM The source code of the attack page is attached to this bug report. For the attack to be successful, this page must be served from an HTTP(not HTTPS) server as HTTPS mode does not allow mixed content requests and Che is run over HTTP. I have already checked with Firefox and Chrome that this is expected behavior. I believe this issue can be mitigated by either checking the Origin header of requests or requiring a session token or cookie for all successful requests.
Project team, policy and process regarding how we deal with vulnerabilities is captured in the handbook: https://www.eclipse.org/projects/handbook/#vulnerability
Hello, I did not include a CWE number in my report. I believe that CWE-352(https://cwe.mitre.org/data/definitions/352.html) describes this bug, as verification of the user's intention will fix this problem. Thank you, Mike
Single user mode is unsecure by design: there is no authentication/authorization mechanism. Any user that is able to connect to the Che server network and knows the URL can control Che and, as a consequence, can start containers on the same Kubernetes namespace where the che-server container runs. This mode is useful when users want to try Che on their local laptop through minikube or minishift (because it requires less resources) but is not recommended on the cloud or on any server on a shared network. Maybe it's just a documentation issue?
The consequence of this problem is that remote attackers can run docker containers on your machine if happen to be running Che in single user mode. I understand that single user mode is made for people who just want to try Che, but I do not believe it's safe to allow any website to create and run Docker containers locally. This issue could be easily remedied by requiring a session token for successful API calls.
To clarify, port 8080 only needs to be open locally for this attack to work.
I have reviewed your video and links. I will try to summarize the attack scenario: 1. A user deploys Che on its laptop 2. The same user visits a remote website 3. Some javascript is executed in the user browser 4. The javascript code starts an arbitrary Che workspace That means that a remote website can control the Che server and start containers locally. That looks like a CSRF indeed. We will try to reproduce it tomorrow. Can you provide more details in the meantime: 1. Are you installing Che on OpenShift or Docker? 2. Are you installing latest Che 6? Do you know exactly what's version? 3. Have you tried using Che v7 instead of Che v6? 4. What's your local OS and browser?
I have verified that Che 7.4-SNAPSHOT (HEAD of current master branch) is also vulnerable to this attack. skabashniuk@redhat.com has provided a fix [1] that should be part of release 7.4.0 (ETA 8th of November) and 7.3.1 (ETA next week). [1] https://github.com/eclipse/che/pull/14921
Hi Mario, I see your comment that you have verified that Che 7.4 is vulnerable so I assume you were able to reproduce this issue. For the sake of completeness, my answers to your questions: 1. Docker 2. 6.19, 7.x 3. Yes 4. My local OS and browsers are: Chrome, Firefox, MacOS and Linux. I've tested the issue with every combination of these.
Thanks for the details Michael and yes I have been able to reproduce the issue, thank you for opening it.
I see that 7.40 is released. Does that mean the patch has been applied? If so, can we close this ticket and make it public?
If a CVE is required, I need somebody from the project team to follow the steps described in the handbook[1]. [1] https://www.eclipse.org/projects/handbook/#vulnerability-cve
I confirm that 7.3.1 and 7.4.0 has been released and both contain the patch. Wayne Beaton I am not sure how we should determine if it needs a CVE or not.
(In reply to Mario Loriedo from comment #12) > I confirm that 7.3.1 and 7.4.0 has been released and both contain the patch. > Wayne Beaton I am not sure how we should determine if it needs a CVE or not. If the impacted content is deployed in the field (i.e. adopters are at risk), then a CVE would certainly be in order. The "Committers only" flag is still on (this restricts the accessibility of this bug). If you left that on on purpose, then a CVE is certainly order. If you didn't leave it on on purpose, then please turn it off. If you're not sure, check with your PMC.
Given that this at least impacts everybody using standalone mode before 7.3.1, I'd argue it's pretty clear that adopters are at risk.
Hello, Is there any update on this? Seeing as we've passed the 60 day mark in the standard 90 day disclosure timeline and have the holidays coming up I thought it might be appropriate to check in.
(In reply to Wayne Beaton from comment #13) > (In reply to Mario Loriedo from comment #12) > > I confirm that 7.3.1 and 7.4.0 has been released and both contain the patch. > > Wayne Beaton I am not sure how we should determine if it needs a CVE or not. > > If the impacted content is deployed in the field (i.e. adopters are at > risk), then a CVE would certainly be in order. > > The "Committers only" flag is still on (this restricts the accessibility of > this bug). If you left that on on purpose, then a CVE is certainly order. If > you didn't leave it on on purpose, then please turn it off. > > If you're not sure, check with your PMC. Eclipse Che Project Team: I need a reply.
PMC says CVE is needed.
(In reply to Wayne Beaton from comment #11) > If a CVE is required, I need somebody from the project team to follow the > steps described in the handbook[1]. > > [1] https://www.eclipse.org/projects/handbook/#vulnerability-cve Hi Wayne, I have look at the steps in the handbook to request a CVE number. And these should be the required informations: project: Eclipse Che version: [6.16.0, 7.3.0] cwe: CWE-352: Cross-Site Request Forgery (CSRF) summary: For Eclipse Che versions 6.16 to 7.3.0, with both authentication and TLS disabled, visiting a malicious web site could trigger the start of an arbitrary Che workspace. Che with no authentication and no TLS is not usually deployed on a public network but is often used for local installations (e.g. on personal laptops). In that case, even if the Che API is not exposed externally, some javascript running in the local browser is able to send requests to it. I will now send an email to security@eclipse.org
Email to the Security Team sent. I haven't unchecked "committer-only" yet. Waiting instructions to do so. Not sure that it was clear in previous comments but version 7.3.1, 7.4.0 and above contain the fix.
I've created a pull request with the central authority. https://github.com/CVEProject/cvelist/pull/2954
> I haven't unchecked "committer-only" yet. Waiting instructions to do so. > Not sure that it was clear in previous comments but version 7.3.1, 7.4.0 and > above contain the fix. I turned it off. It needs to be publicly visible when we submit.
