New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CVE-2018-1000840 - XXE in loadXML() #5706
Comments
|
Ouch. The nasty thing about that is that the actual PDE file looks completely innocuous.
I wonder if that could be disabled by default and enabled with a setting -- or just disabled. It seems like remote DTDs would be an unusual use case for a Processing user. |
|
Yes, the best solution would be to disable DTDs by default and provide a method to manually enable them, even though I agree it does not seem like a common use case. |
|
The issue has been recognized as a vulnerability and assigned CVE-2018-1000840. |
|
I'm guessing that such a change would involve updating the XML source libraries (if they are incorporating it upstream) or changing something (?) around here.... https://github.com/processing/processing/blob/master/core/src/processing/data/XML.java#L121 |
|
Was this issue ever addressed? |
|
I do not believe it was addressed -- at least, I don't see any changes in XML.java history. The underlying javax.xml code source is pinned to Java 8u202, so nothing has changed there. https://github.com/processing/processing/blob/master/core/src/processing/data/XML.java#L160 If someone was interested in developing a patch to submit, I'm guessing that it would probably be added to XML.java and based on the Java DocumentBuilderFactory example here: https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html But, I am not a core dev -- just suggesting potential ways forward. |
|
I've already told the creator of the bug (and now CVE, FFS) that this is an overwrought response to an almost entirely unlikely scenario. This is a development environment. It's like filing bugs for C++ because But if someone wants to contribute a fix, that's great. Sounds like it'd be fairly straightforward. It's just way, way down on the priority list relative to actual problems people are having with the software. |
Ah I see, well I'm assuming you've contacted CVE in order to reject/dispute this vulnerability ? |
|
No, again, I need to spend my very limited free time on actual problems, not theoretical ones. Hopefully someone will contribute a fix if they feel strongly about it. I'm not an organization, I'm one person, working in his free time on this thing that I'm giving away for free. I can't do everything, and I need help. |
Issue
An XML External Entity attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser. This attack may lead to the disclosure of confidential data since it allows arbitrary file inclusion in the XML and the automated execution of HTTP requests (which can be used to exfiltrate the included data) during the parsing of the XML.
Steps to reproduce
Example Processing script
Example XML file
Example remote DTD (as stored at the url referenced above)
Further clarification
The proof of concept provided above retrieves from the remote server the DTD specification. During the execution of loadXML the DTD is then parsed, reading in the example the content of /sys/power/image_size.
The content of the file is than transmitted through an HTTP request (row 2 of the DTD) to the remote server, that returns the content of $_REQUEST, providing the console output.
Remediation
https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet
The text was updated successfully, but these errors were encountered: