according to some vulnerability databases, dom4j is affected by CVE-2023-45960

[ManfredSchenkIOSB]

According to https://vuldb.com/?id.243331, dom4j is affected by CVE-2023-45960.

When will there be a fix?

[chadlwilson]

Is it a real issue? I wonder if it was disclosed appropriately

OSSIndex seems to think it's an issue https://ossindex.sonatype.org/vulnerability/CVE-2023-45960 but the sole information available is in Chinese and there is no OSSIndex summary so it's a little difficult to understand how they assessed it and gave it a CVSS # or assigned affected versions.

https://github.com/joker-xiaoyan/XXE-SAXReader/tree/main#xxe-saxreader

Google translate:

The XML injection used this time is about SAXReader<=v.2.1.4 version. The core is to limit the setFeature order of XML injection.

focus: If you first restrict the external parameter entities and then restrict the external general entities, you can achieve the function of restricting both. If you first restrict the external general entity and then restrict the external parameter entity, you cannot restrict the two entities, and you can only restrict the external parameter.

[pwagland]

If I understand the code directly, dom4j doesn't use these directly anyway, it passes it through to the underlying SaxReader, which is creates via JAXP. So, if this is an issue, then it's an issue with the underlying SAX parser, not with dom4j?

If I understand the POC correctly, they are saying that:

            reader.setFeature("http://xml.org/sax/features/external-parameter-entities",false);
            reader.setFeature("http://xml.org/sax/features/external-general-entities",false);

works correctly, but

            reader.setFeature("http://xml.org/sax/features/external-general-entities",false);
            reader.setFeature("http://xml.org/sax/features/external-parameter-entities",false);

causes the external-general-entities to get reset to true?

In any case, if this is true, it seems to be an issue with the underlying SAX parser, not with dom4j itself? Is that a correct understanding?

[ecki]

Saxreader security is a mine field, so yes it’s not dom4j fault, however there should be no harm in switching the sequence, asserting the flags and also setting FSP.

recent JDK parses are not affected as claimed here joker-xiaoyan/XXE-SAXReader#1 (comment)

[FilipJirsak]

No, dom4j is not affected by that. More precisely, CVE-2023-45960 is not a vulnerability. The setFeature method sets the features of the XML parser in use - in fact, it just invokes the setFeature method of the underlying SAX parser. Different features of the XML parser can be safe in one case and unsafe in another - that's how it works in the world.

By the way, CVEs have become quite useless Just because something is assigned a CVE doesn't mean it's a vulnerability. It just means that someone came along and got assigned a CVE number.

[jwhance]

Unfortunately this is not resolved. There is a CVE, right or wrong, against dom4j and idiotic tools like Sonatype's Nexus, used by many companies including mine, are now blocking the library and anything that references it. Yes, it's a problem!

[chadlwilson]

Unfortunately this is not resolved. There is a CVE, right or wrong, against dom4j and idiotic tools like Sonatype's Nexus, used by many companies including mine, are now blocking the library and anything that references it. Yes, it's a problem!

There are parallel attempts to both withdraw the CVE and also get Sonatype to detach it from DOM4J after the original reporter couldn't provided a replication (whether at dom4j or at an underlying level).

That's about all that can be done. Not much point railing on the ticket here. Better to help your company understand the weaknesses in the CVE process and provide a mechanism to review and suppress false positives.

[jwhance]

I'd love to help then understand but they have been sold a bill of good by Sonatype. The fight goes way over my pay grade unfortunately.

[chadlwilson]

Well, as paying customers, perhaps use the support channels that you pay Sonatype for, to get them to correct inaccurate information. You’re paying for it, and are thus likely to get further than those of us in OSS.

[pwagland]

Well, as paying customers, perhaps use the support channels that you pay Sonatype for, to get them to correct inaccurate information. You’re paying for it, and are thus likely to get further than those of us in OSS.

This is the way. Part of Sonatypes, and other SBOM providers value add is exactly this. So, get them to up their game.

[carlosame]

FWIW I pinged Github and they withdrew CVE-2023-45960.

[oberoimanvi]

If its not a real vulnerability, is there a way we can request NIST to lower the score of this CVE. As it is create a misunderstanding for companies/customers.

[chadlwilson]

We can try - but NVD have a ridiculous backlog at the moment, they took months to respond to a simple correction in affected ranges for a separate CVE I interacted with them on.

For this one, they had the original reporters comment that it could not be replicated at the time of their 'analysis' and still gave it such a rating it seems reasonably clear that they are not interested in accuracy.

[carlosame]

If its not a real vulnerability, is there a way we can request NIST to lower the score of this CVE. As it is create a misunderstanding for companies/customers.

I asked NIST to withdraw the CVE but it didn't work.

We can try - but NVD have a ridiculous backlog at the moment, they took months to respond to a simple correction...

They actually updated the CVE on Nov. 6 (a week after I requested the withdrawal), to remove the ** DISPUTED ** warning. Not disputed anymore it seems.

[chadlwilson]

NIST don't withdraw/reject CVEs, only MITRE can do that. But they can unlink it from affected products or un-rate its risk I suppose.

They actually updated the CVE on Nov. 6 (a week after I requested the withdrawal), to remove the ** DISPUTED ** warning. Not disputed anymore it seems.

I noticed this too, which is rather confusing as that content and designation is supposed to come from the upstream MITRE (where it is still disputed), so I've no idea what they are doing at the NIST NVD. Effectively the NVD are an unaccountable black box regarding processes and commitment to the community which makes it even more bizarre as to why everyone blindly trusts their assessments, which are clearly made with zero actual knowledge (or even review of publicly available information) in some cases like this one.

[carlosame]

NIST don't withdraw/reject CVEs, only MITRE can do that. But they can unlink it from affected products or un-rate its risk I suppose.

The form that I used had a choice for "removal" or "deletion", do not recall the exact word.

[carlosame]

NIST don't withdraw/reject CVEs, only MITRE can do that. But they can unlink it from affected products or un-rate its risk I suppose.

Sorry my bad, I looked at the receipt email and I did contact MITRE, not NIST/NVD. I requested a "rejection".

[chadlwilson]

On the plus side, it is gone from both GitHub and Sonatype OSS Index now. I've tried again with the NIST NVD, pointing out that it's not "disputed", it's completely non-reproducible as described by and acknowledged by the original reporter - so in this specific case, it's irrelevant as to the safety (or not) of XML parser feature setting or whether it's a vulnerability in the underlying parser vs. dom4j itself.

joker-xiaoyan/XXE-SAXReader#1 (comment)

Of course that won't stop us going down some kafka-esque rabbithole where information accepted on face value from source X cannot also be rejected on face value from the same source X.....

[chadlwilson]

The CVE is now entirely rejected so it should disappear from everywhere downstream of MITRE (including NVD) some time soon, if not already.

[carlosame]

The CVE is now entirely rejected so it should disappear from everywhere downstream of MITRE (including NVD) some time soon, if not already.

It appears as Rejected at NVD as well.