Community
Participate
Working Groups
From the Security Team inbox: -- One of the default pre-packaged Theia extensions is “Mini-Browser”. This extension provides a browser widget to preview various file types inside the IDE. It works by spawning a local web server to serve files and then rendering them using a dedicated iframe inside Theia. The mini-browser extension will be listening on a randomly assigned port (0 as defined in /packages/core/src/node/backend-application.ts), exposing the whole host filesystem through its custom endpoint without restrictions on the requester’s origin. This design is particularly risky, since through a DNS rebinding attack or a drive-by download of a carefully crafted exploit, it is possible for an attacker to read every file on the victim’s filesystem, given its path. --
Project team, there is help regarding how we handle vulnerabilities in the handbook. https://www.eclipse.org/projects/handbook/#vulnerability
Created attachment 280153 [details] The original report sent by Doyensec A screen capture of the exploit was also sent and is available on request.
One possible solution for Mini-browser would be to require a cryptographically secure token before serving the content. This is easily implementable by adding a unique token as a GET parameter when loading the iframe in Theia, checking it at each request. The full report is provided in attachment 280153 [details].
Still wrapping my head around this report, so take with a grain of salt... 1 - I think that a user running Theia on their physical computer would be unlikely to be affected - one needs to explicitly start the backend with --hostname=0.0.0.0 so that connections from outside localhost will be accepted - even if one does that, many OS will by default block such requests. That's the case on my Ubuntu work machine at least, unless I take measures to I open the firewall port. - I am guessing that the Electron version of Theia apps would not enable accepting connections from outside localhost but I have not confirmed 2 - cloud or remote Theia backend deployment Theia does not provide authentication. That is left for another layer, e.g. Eclipse Che, Gitpod or whatever workspace server would provide it. They will presumably have all incoming requests going through e.g. Keycloak, and any non-authenticated request will not reach the Theia backend. I guess if one could hijack a user's browser, the exploit could be used, but the attacker would also be able to access the main Theia endpoint... 3 - the only case I can see that would reproduce this issue easily is if Theia is run on a remote server with the backend accepting connections from anyone (--hostname=0.0.0.0) and without an authentication mechanism such as Keycloak. But in that case most likely the main Theia backend endpoint would also be left wide open. In that scenario, the mini-browser end-point should be the least of your worries - one can use Theia's terminal to read any file or ssh/scopy anything to a remote host :) I may well be missing something and welcome being proven wrong :)
Created attachment 280160 [details] Arbitrary File Read PoC Screen capture of the attack chain: from the user visiting an attacker-controlled page to the C2 server exfiltration
Screen capture of the attack chain: from the user visiting an attacker-controlled page to the C2 server exfiltration
(In reply to Marc Dumais from comment #4) > Still wrapping my head around this report, so take with a grain of salt... > > 1 - I think that a user running Theia on their physical computer would be > unlikely to be affected > > - one needs to explicitly start the backend with --hostname=0.0.0.0 so > that connections from outside localhost will be accepted > - even if one does that, many OS will by default block such requests. > That's the case on my Ubuntu work machine at least, unless I take measures > to I open the firewall port. > - I am guessing that the Electron version of Theia apps would not enable > accepting connections from outside localhost but I have not confirmed > > 2 - cloud or remote Theia backend deployment > Theia does not provide authentication. That is left for another layer, e.g. > Eclipse Che, Gitpod or whatever workspace server would provide it. They will > presumably have all incoming requests going through e.g. Keycloak, and any > non-authenticated request will not reach the Theia backend. I guess if one > could hijack a user's browser, the exploit could be used, but the attacker > would also be able to access the main Theia endpoint... > > 3 - the only case I can see that would reproduce this issue easily is if > Theia is run on a remote server with the backend accepting connections from > anyone (--hostname=0.0.0.0) and without an authentication mechanism such as > Keycloak. But in that case most likely the main Theia backend endpoint would > also be left wide open. In that scenario, the mini-browser end-point should > be the least of your worries - one can use Theia's terminal to read any file > or ssh/scopy anything to a remote host :) > > I may well be missing something and welcome being proven wrong :) Hey Marc, thank you for your input. In the attack scenario for this vulnerability we were thinking about the #1 case you mentioned: a user running Theia on their physical computer, who is browsing a web page with his browser of choice. The full report attached describes this scenario, but if something is not clear let me know. I recorded a small PoC of the attack to make things clearer (attachment 280160 [details]).
(In reply to Lorenzo Stella from comment #7) > > Hey Marc, thank you for your input. In the attack scenario for this > vulnerability we were thinking about the #1 case you mentioned: a user > running Theia on their physical computer, who is browsing a web page with > his browser of choice. > The full report attached describes this scenario, but if something is not > clear let me know. I recorded a small PoC of the attack to make things > clearer (attachment 280160 [details]). Thanks for the report, Lorenzo. I've also started to read about DNS rebinding, which I was not familiar-with. Interesting but scary stuff :)
Maybe I missed something, but besides the endpoint from mini-browser that is providing access to read the filesystem, Theia provides a websocket protocol that can be used to read and write the FS as well as **running arbitrary processes on the user's machine**. So, as Marc already mentioned it is the responsibility of the Theia operator to run it in a secure environment.
(In reply to Sven Efftinge from comment #9) > Maybe I missed something, but besides the endpoint from mini-browser that is > providing access to read the filesystem, Theia provides a websocket protocol > that can be used to read and write the FS as well as **running arbitrary > processes on the user's machine**. > So, as Marc already mentioned it is the responsibility of the Theia operator > to run it in a secure environment. Sven, Marc, I feel like the scenario our report is describing may not be clear enough and I should add a bit of background. Theia Desktop IDEs can also be packaged and distributed as Electron Desktop Apps to the final users. In our attack scenario, a standard user is running an Electron Theia-based IDE on his local workstation when he visits an attacker-controlled web page with his browser. 1. As a first stage of the exploit, the page ("A") initiates the download of an .html file in a new tab (the second stage, "B"). 2. (A) redirects the victim to the (B) page through the local mini-browser web server, by setting its window's location to e.g. "http://localhost:61403/mini-browser/Users/alice/Downloads/exploit.html". 3. Now the attacker has access to the localhost origin thanks to (B) and can request arbitrary files located in the victim's filesystem since they will be served by the mini-browser extension. 4. (B) can finalize the chain by exfiltrating the local files in various ways (e.g. computing the base64 of the exfiltrated file and sending it via form/xhr). Let me know if anything is unclear,
Sven, Marc, Please, let me know if the scenario I described is clearer now or if you have any more questions. Thanks,
(In reply to Lorenzo Stella from comment #11) > Sven, Marc, > > Please, let me know if the scenario I described is clearer now or if you > have any more questions. > > Thanks, Hi Lorenzo, According to the outlined scenario, am I correct in thinking that the malicious request to the mini-browser end-point would be coming from a "localhost:<port>" origin? If so, it seems that it would then do no good to filter requests based on their origin to exclude non-local ones, as a way to address this report? I ask, because I have seen this being suggested as a way to avoid DNS Rebinding attacks. For example: https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2018/august/singularity-of-origin-a-dns-rebinding-attack-framework/ "DNS rebinding attacks can be prevented by validating the "Host" HTTP header on the server-side to only allow a set of whitelisted values. For services listening on the loopback interface, this set of whitelisted host values should only contain localhost and all reserved numeric addresses for the loopback interface, including 127.0.0.1. For instance, let's say that a service is listening on address 127.0.0.1, TCP port 3000. Then, the service should check that all HTTP request "Host" header values strictly contain "127.0.0.1:3000" and/or "localhost:3000". If the host header contains anything else, then the request should be denied." Also this one here has some nice parallels with (Electron) Theia, and documents a similar filtering solution: https://prathamesh.tech/2019/09/02/dns-rebinding-attacks-protection-in-rails-6/ Thanks, Marc
(In reply to Lorenzo Stella from comment #10) > (In reply to Sven Efftinge from comment #9) > > Maybe I missed something, but besides the endpoint from mini-browser that is > > providing access to read the filesystem, Theia provides a websocket protocol > > that can be used to read and write the FS as well as **running arbitrary > > processes on the user's machine**. > > So, as Marc already mentioned it is the responsibility of the Theia operator > > to run it in a secure environment. > > Sven, Marc, > > I feel like the scenario our report is describing may not be clear enough > and I should add a bit of background. > > Theia Desktop IDEs can also be packaged and distributed as Electron Desktop > Apps to the final users. In our attack scenario, a standard user is running > an Electron Theia-based IDE on his local workstation when he visits an > attacker-controlled web page with his browser. > > 1. As a first stage of the exploit, the page ("A") initiates the download of > an .html file in a new tab (the second stage, "B"). > 2. (A) redirects the victim to the (B) page through the local mini-browser > web server, by setting its window's location to e.g. > "http://localhost:61403/mini-browser/Users/alice/Downloads/exploit.html". > 3. Now the attacker has access to the localhost origin thanks to (B) and can > request arbitrary files located in the victim's filesystem since they will > be served by the mini-browser extension. > 4. (B) can finalize the chain by exfiltrating the local files in various > ways (e.g. computing the base64 of the exfiltrated file and sending it via > form/xhr). > > Let me know if anything is unclear, Hi Lorenzo, (1) Would the attacker somehow make the user download an html file on the user's disk? If this is the case, the user would have to willingly accept from the confirmation dialog. Do you see a different way of downloading such a file? (2) I don't really understand how the attacker would then make the user open such a file in the mini-browser. Best I can imagine would be through some kind of link the user would have to click, but if you want it in the mini-browser, the user has to pretty much copy/paste it by himself. Is there a different mechanism? (3) and (4) both sound fair, was able to replicate. If (1) and (2) cannot be implicitly triggered (without the user knowing what is happening), then this looks like the situation when a user is proposed to download a malicious executable and then has to manually execute it... Which in my opinion is out of Theia's security scope. Also, for (2) to somehow happen, the attacker would have to guess the more-or-less random port assigned to electron's Express application (you used 61403, is that on purpose?). After playing around with this, the only way I found to "execute" html/js files within a Theia's application localhost:xxx context was by opening a file via Theia's navigator with `Open With > Preview`. Is there a different way? Finally, AFAIK if we want to display rendered html files in Theia applications, we have to serve them. But if malicious scripts can be executed at this point, then do you see a way of mitigating the issue?
Ok, my bad, just noticed there was a full pdf report attached. My questions still hold, in order to better understand how this would play for an Electron application. On the other hand, you mention how it could be fixed: > Mini-browser should require a cryptographically secure token before serving > the content. This is easily implementable by adding a unique token as a GET > parameter when loading the iframe in Theia, checking it at each request. In this case, how to ensure that the token is securely passed from one end to the other? If the mini-browser endpoint is waiting for a token, how to ensure that a sane frontend gets the token, but not a malicious one? In the case of a localhost application, I guess the attacker can get the token on behalf of the user using a DNS rebind in order to make a request for that token on the localhost side. How should a secure process go?
(In reply to Marc Dumais from comment #12) > > Hi Lorenzo, > > According to the outlined scenario, am I correct in thinking that the > malicious request to the mini-browser end-point would be coming from a > "localhost:<port>" origin? Depending on how an attacker chooses to exploit this: in case of a DNS rebinding attack, the origin will be a different one (e.g. attacker.com), resolving to 127.0.0.1. In case of the drive-by, it will have localhost:<port> as you said and it will be indistinguishable from a legit request. > > If so, it seems that it would then do no good to filter requests based on > their origin to exclude non-local ones, as a way to address this report? > The solution advanced in the report should mitigate any possible abuse (both the DNS rebinding and drive-by).
(In reply to Paul Maréchal from comment #13) > Hi Lorenzo, > > (1) Would the attacker somehow make the user download an html file on the > user's disk? If this is the case, the user would have to willingly accept > from the confirmation dialog. Do you see a different way of downloading such > a file? This is correct. As you can see from the video PoC attachment 280160 [details], in Chrome programmatically opening a new tab and serving the content with `Content-Disposition: attachment;` is enough. > > (2) I don't really understand how the attacker would then make the user open > such a file in the mini-browser. Best I can imagine would be through some > kind of link the user would have to click, but if you want it in the > mini-browser, the user has to pretty much copy/paste it by himself. Is there > a different mechanism? > The mini-browser is nothing more than a web server listening on localhost. The mini-browser is reachable from the browser visiting `http://localhost:61403/mini-browser/<absolute file path>`. 61403 is a random port that can be brute-forced with little effort from the attacker. (In reply to Paul Maréchal from comment #14) > On the other hand, you mention how it could be fixed: > > > Mini-browser should require a cryptographically secure token before serving > > the content. This is easily implementable by adding a unique token as a GET > > parameter when loading the iframe in Theia, checking it at each request. > > In this case, how to ensure that the token is securely passed from one end > to the other? If the mini-browser endpoint is waiting for a token, how to > ensure that a sane frontend gets the token, but not a malicious one? In a secure "flow", the Electron application should: 1) Generate a secret token from a CSPRNG, only known to the Electron app and the mini-browser web server. 2) For every request made to the mini-browser from the Electron context, attach the token (e.g. as URI parameter or header) to the request. 3) The token should be checked by the mini-browser to verify that the request is legit, otherwise the request should be discarded. Requiring the token will break any possible exploit from an attacker. Again, let me know if I wasn't clear enough,
(In reply to Lorenzo Stella from comment #16) > 61403 is a random port that can be brute-forced with little effort from the > attacker. Ok > In a secure "flow", the Electron application should: > 1) Generate a secret token from a CSPRNG, only known to the Electron app and > the mini-browser web server. > 2) For every request made to the mini-browser from the Electron context, > attach the token (e.g. as URI parameter or header) to the request. > 3) The token should be checked by the mini-browser to verify that the > request is legit, otherwise the request should be discarded. > > Requiring the token will break any possible exploit from an attacker. I started to prototype this where on each startup, a token would be written on disk by the backend, and the electron-renderer code will do a `fetch("file://path/...")` using the `file` scheme, in order to be able to pass the token around. My understanding is that such a token cannot simply be served via http to the frontend, since anyone could make such a request IIUC? Hence why I tried using the file scheme. Not sure if this is the best way of going about it. IIUC still, this mechanism should only prevent drive-by attacks? Also, we were wondering if according to your findings, all types of applications would be affected by these attacks? Both localhost and non-localhost apps?
(In reply to Paul Maréchal from comment #17) > (In reply to Lorenzo Stella from comment #16) > > 61403 is a random port that can be brute-forced with little effort from the > > attacker. > > Ok > > > In a secure "flow", the Electron application should: > > 1) Generate a secret token from a CSPRNG, only known to the Electron app and > > the mini-browser web server. > > 2) For every request made to the mini-browser from the Electron context, > > attach the token (e.g. as URI parameter or header) to the request. > > 3) The token should be checked by the mini-browser to verify that the > > request is legit, otherwise the request should be discarded. > > > > Requiring the token will break any possible exploit from an attacker. > > I started to prototype this where on each startup, a token would be written > on disk by the backend, and the electron-renderer code will do a > `fetch("file://path/...")` using the `file` scheme, in order to be able to > pass the token around. > > My understanding is that such a token cannot simply be served via http to > the frontend, since anyone could make such a request IIUC? Hence why I tried > using the file scheme. Not sure if this is the best way of going about it. > > IIUC still, this mechanism should only prevent drive-by attacks? > > Also, we were wondering if according to your findings, all types of > applications would be affected by these attacks? Both localhost and > non-localhost apps? Paul, I'm not familiar enough with the codebase to suggest what's the best way to pass variables between the main electron theia and its modules. The vulnerability reported only affects local installations of Electron Theia (e.g. https://github.com/theia-ide/theia-apps/tree/master/theia-electron) using the `mini-browser` extension. Having a token-based mitigation will protect against every possible attack scenario (both from drive-by and DNS rebinding attacks), since an attacker will always need the secret token in order to make the mini-browser server render his arbitrary "file". This token can be passed in various ways (as a GET parameter, a custom header, or even using the standard HTTP authentication format username:token). Thanks for dedicating time to the issue,
Cannot we render mini-browser in Electron webview instead without Node integration and isolated from the main app state? See docs: https://github.com/electron/electron/blob/master/docs/tutorial/security.md#isolation-for-untrusted-content > To display remote content, use the <webview> tag or BrowserView, make sure to disable the nodeIntegration and enable contextIsolation.
(In reply to Anton Kosyakov from comment #19) > Cannot we render mini-browser in Electron webview instead without Node > integration and isolated from the main app state? > > See docs: > https://github.com/electron/electron/blob/master/docs/tutorial/security. > md#isolation-for-untrusted-content > > > To display remote content, use the <webview> tag or BrowserView, make sure to disable the nodeIntegration and enable contextIsolation. The iframe in which the mini-browser preview is rendered seems already sandboxed, having "allow-same-origin, allow-scripts, allow-popups, allow-forms, allow-modals". By the way, this is not a possible fix for the reported vulnerability, since the threat model would be different (a user willingly previewing an HTML file with malicious JS code vs a user browsing the web, having an Electron-based Theia IDE running).
@anton I am about to open a PR where I remove the mini-browser HTTP endpoint when running on Electron. Instead, it will open files using `file://`, since everything should be local. I would count on your help to get this merged: https://github.com/eclipse-theia/theia/compare/mp/mini-browser?expand=1 Although, this is a first step if we want to do things properly. One of my concerns is that my current change only closes one endpoint on the Node backend. All others endpoints are still accessible on localhost though. While I understand the advantages of running the backend services in a sub-process, I think we should remove the socket communication and instead rely on IPC of some sort to communicate between backend/frontend when using Electron. Right now we should focus on fixing the mini-browser issue, but I'd like to have your opinion on what I think is a "bigger security hole" for Electron applications.
@paul It makes the arch complex. We want to single source for electron and browser. It is always better to rely on the web tech, instead of maintaining the same with Electron APIs. The mini-browser will be also rewritten as a webview which will remove all your changes. I don't think we should move with this.
I'd be in favor of using IPC to fetch a token (e.g a generated UUID) from the backend, which then is sent with each request using a cookie or so. It would be a minimal change and solve the issue AFAIU.
This should be now fixed. See https://github.com/eclipse-theia/theia/pull/7205
Hi @Lorenzo, Do you need to confirm that the fix we merged correctly addresses the reported issue? We believe it does, but security can be tricky.
Wayne - any advice about going forward with this vulnerability? I have started preparing for the CVE, but I am unsure if we should get someone else to validate our fix, before proceeding?
(In reply to Marc Dumais from comment #26) > Wayne - any advice about going forward with this vulnerability? I have > started preparing for the CVE, but I am unsure if we should get someone else > to validate our fix, before proceeding? That's the project team's call. Note that we're overdue to disclose this vulnerability, so we'll have remove the "committers only" flag soon anyway.
Ok, thanks Wayne. I think the project's committers interested in this issue are in cc on this bugzilla. The fix gets my "+1", as well as I assume Anton's (who reviewed it)? Sven and Rob: any objections to going forward with the current fix?
No concerns from me. Kind regards, Rob
Draft CVE: project: Eclipse Theia CVE-ID: CVE-2020-xxx version: all version of @theia/mini-browser extension from 0.3.9 to 0.15.0 (inclusive) CWE: CWE-345: Insufficient Verification of Data Authenticity summary: One of the default pre-packaged Theia extensions is “Mini-Browser”, published as "@theia/mini-browser" on npmjs.com. This extension, for its own needs, exposes a HTTP endpoint that allows to read the content of files on the host's filesystem, given their path, without restrictions on the requester’s origin. This design is vulnerable to being exploited remotely through a DNS rebinding attack or a drive-by download of a carefully crafted exploit. --- Note: the fix for this vulnerability made it in Theia 0.16.0. Note2: I am not sure which CWE is the closest match for this vulnerability. Several seem like they could work. Here are the runner-ups: Other CWEs that could match this vulnerability: CWE-264: Permissions, Privileges, and Access Controls CWE-20: Improper Input Validation CWE-300: Channel Accessible by Non-Endpoint CWE-352: Cross-Site Request Forgery (CSRF) If someone has an opinion that one of the alternate CWE fits better, please comment.
(In reply to Marc Dumais from comment #25) > Hi @Lorenzo, > > Do you need to confirm that the fix we merged correctly addresses the > reported issue? We believe it does, but security can be tricky. Hello Marc, Good job! Aside from a small improvement (https://github.com/eclipse-theia/theia/pull/7205/files#r390306290) I think you tackled it very well. (In reply to Marc Dumais from comment #30) > Draft CVE: > > > project: Eclipse Theia > CVE-ID: CVE-2020-xxx > > version: all version of @theia/mini-browser extension from 0.3.9 to 0.15.0 > (inclusive) > > CWE: CWE-345: Insufficient Verification of Data Authenticity > > summary: One of the default pre-packaged Theia extensions is “Mini-Browser”, > published as "@theia/mini-browser" on npmjs.com. This extension, for its own > needs, exposes a HTTP endpoint that allows to read the content of files on > the host's filesystem, given their path, without restrictions on the > requester’s origin. This design is vulnerable to being exploited remotely > through a DNS rebinding attack or a drive-by download of a carefully crafted > exploit. > > --- > > Note: the fix for this vulnerability made it in Theia 0.16.0. > > Note2: I am not sure which CWE is the closest match for this vulnerability. > Several seem like they could work. Here are the runner-ups: > > Other CWEs that could match this vulnerability: > CWE-264: Permissions, Privileges, and Access Controls > CWE-20: Improper Input Validation > CWE-300: Channel Accessible by Non-Endpoint > CWE-352: Cross-Site Request Forgery (CSRF) > > If someone has an opinion that one of the alternate CWE fits better, please > comment. I would personally go with CWE-200: Information Exposure or CWE-264: Permissions, Privileges, and Access Controls, but it really doesn't matter that much to me.
I've pushed CVE-2019-17636 to the central authority. Pull request: https://github.com/CVEProject/cvelist/pull/3381
The CVE has been published. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17636 Plase mark this RESOLVED/FIXED at your earliest convenience.
(In reply to Wayne Beaton from comment #33) > Plase mark this RESOLVED/FIXED at your earliest convenience. Wayne, is this directed at the project or the originator?
> Wayne, is this directed at the project or the originator? The project team. Is this bug fixed?
Fixed thanks to: https://github.com/eclipse-theia/theia/pull/7205 Small follow-up (improvement): https://github.com/eclipse-theia/theia/pull/7308
