Community
Participate
Working Groups
Created attachment 280455 [details] step by step guide how to reproduce the problem Hi, I’d like to report a XSS within the html report files generated from the Memory Analyzer plugin. Details you could find into the attached step-by-step pdf document. Best Regards, Iassen Minov
/cc the Eclipse Memory Analyzer project lead. Information regarding how the project team can deal with the vulnerability is documented in the Eclipse Project Handbook. https://www.eclipse.org/projects/handbook/#vulnerability
Krum, I need a response from the project team, please.
Hi Wayne, appologies for the delay. I have reviewed the documentation, but am still not quite sure what to do. My thoughts on the issues so far: - first of all - yes, that is an issue. In MAT we extract certain values (e.g. Strings' values, Thread names, etc...) out of the heapdump and we also have some functionality to render the analysis as HTML. We've overlooked that in such case we have to take care to do proper escaping to avoid the described attack - second, I think it is important to get an estimate of how critical the issue is/what its priority is. My personal estimate is that the risk is low. I can think of the following attach scenarios: -- someone creates a crafted heap dump and sends it to someone else for analysis, e.g. as part of a support ticket / question -- the owner of a service analyses a crash of the service and in the heap dumps there are crafted Strings The part I didn't figure out in the linked document: - how can we come up to an estimation of the priority - what disclosure process to use (silent or not) - is the project team obliged to fix the issues in a certain timeframe - what exactly is expected from the project team as a statement (is this write-up ok?), etc... Are these all up to the project team to decide? I personally won't be able to spend any time on MAT in the next couple of weeks. I will add Andrew Johnson to CC as he is the one doing 90% of the code changes recently. And I will add to CC also Kevin Grigorenko - the other committer who has recently done changes to MAT.
We need to: 1. find the locations to escape HTML inserts 2. decide on an escaping technique a. own code. If simple - possibility of errors if complex. b. library code. Library code may need third-party code approval, so could we find code already in Eclipse or Orbit. c. Rewrite using HTML document generation APIs - bigger MAT changes and need approved third-party code. 3. decide how we ship the fix a. Version 1.10 - as we have already made API changes since 1.9.1, but we need to complete those big changes (multi-threaded parsing, OQL enhancements) including documentation before we are ready to ship. b. Version 1.9.2 - but we should have to branch the code to the 1.9.1 point and fix in both master and 1.9.2, which is more work.
1.The main areas to change are: a. LeakHunterQuery.java b. ComponentReportQuery.java c. also HTMLPieChartRenderer for any data derived from the dump, including thread names, class loader names. We also need to consider actual class names, because although Java class names aren't risky the HPROF format allows any text. Also consider duplicate char arrays in the component report. This is a particular problem as although the application may be trustworthy it may end up processing itself untrusted character data which will get into the HPROF dump. 2.Our HTMLUtils.escapeText() routine should be sufficient for body text. (Double-quote also needs to be escaped for attributes). 3.I have some prototype changes, but don't know how to share them yet. Gerrit has a private option but some people don't recommend it for security fixes: https://gerrit-review.googlesource.com/Documentation/intro-user.html#security-fixes The other idea is to attach it here as a patch. Eventually it will have to go into Gerrit and be built and the changes will be more visible.
Created attachment 281335 [details] Escaping HTML in TextResult and some HTML tests I have escaped all the thread names, class names, class loader names and char[] values that I can see in HTML results. The tests improve HTML validity. They won't spot unescaped class names etc. as they don't normally contain troublesome characters, but may spot unmatched tags and some double escaping.
New Gerrit change created: https://git.eclipse.org/r/155815
Gerrit change https://git.eclipse.org/r/155815 was merged to [1.9.x]. Commit: http://git.eclipse.org/c/mat/org.eclipse.mat.git/commit/?id=50583dbf03a4dd4a544f0ded7a2e1d0f33a466c1
New Gerrit change created: https://git.eclipse.org/r/155835
Gerrit change https://git.eclipse.org/r/155835 was merged to [master]. Commit: http://git.eclipse.org/c/mat/org.eclipse.mat.git/commit/?id=884033769379f55484626eb72ff373f75d84d258
I applied Andrew's patch: - to a new 1.9.x branch - I am preparing a 1.9.2 service release with the security fixes and will be able to publish it in the next days - to the master branch, so that snapshots builds also get fixed Once the 1.9.2 release is available I will announce the issue and the fixes on our mailing list. I'm also planing to contribute the 1.9.2 bits to the 2020-03 simrel M1.
Today I made the Simrel 2020-03 M1 contribution. I created an new release entry for the 1.9.2 release on the projects page. I already prepared the content on the download server. My plan is to publish links to the new content on MAT's web site tomorrow and announce the release (and the issue) via our mailing list.
Do you believe that we should assign a CVE to this vulnerability and report it to Mitre? https://www.eclipse.org/projects/handbook/#vulnerability-cve
Yes, I think we should assign a CVE. I'll discuss privately with the other committers and then add it here.
Draft CVE [CVE-ID]: CVE-2020- [PRODUCT]: Eclipse Memory Analyzer [VERSION]: All versions prior to version 1.9.2 [PROBLEMTYPE]:CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') [REFERENCES]: CONFIRM:https://bugs.eclipse.org/bugs/show_bug.cgi?id=552542 [DESCRIPTION]: Eclipse Memory Analyzer version 1.9.1 and earlier is subject to a cross site scripting (XSS) vulnerability when generating an HTML report from a malicious heap dump. The user must chose todownload, open the malicious heap dump and generate an HTML report for the problem to occur. The heap dump could be specially crafted, or could come from a crafted application or from an application processing malicious data. The vulnerability is present whena report is generated and opened from the Memory Analyzer graphical user interface, or when a report generated in batch mode is then opened in Memory Analyzer or by a web browser. The vulnerability could possibly allow code execution on the local system whenthe report is opened in Memory Analyzer. [ASSIGNINGCNA]: Eclipse Foundation Thanks to Iassen Minov for reporting the issue.
I've assigned CVE-2019-17634. Let me know when you're ready and we'll remove the "committers-only" flag and push the report.
We are ready. You can submit the report.
Pull request: https://github.com/CVEProject/cvelist/pull/3051
