search

hunterhacker / jdom

Java manipulation of XML made easy
Other
348 stars 118 forks source link

Got security warning on JDom2 2.0.6: CVE-2021-33813 #189

Closed steinarb closed 2 years ago

steinarb commented 3 years ago

I got a security warning on JDom 2.0.6, because of CVE-2021-33813: https://nvd.nist.gov/vuln/detail/CVE-2021-33813

From the severity of CVE-2021-33813 it looks like this is something that needs to be fixed.

albertus82 commented 3 years ago

@hunterhacker did you get any answers from Sonatype? You might comment OSSRH-2219, I think if you can prove that you are the owner of the jdom.org domain, they will be able to authorize you to publish to Maven Central using the groupId org.jdom.

Paradox98 commented 2 years ago

Is there any progress on this issue?

hunterhacker commented 2 years ago

@eneklo, reach out to me at jhunter@servlets.com please. I'm curious why my test runs don't match yours.

hunterhacker commented 2 years ago

Others can test http://jdom.org/dist/binary/jdom2-2.0.6.1-maven-bundle.jar in the meanwhile.

ar commented 2 years ago

FYI, Worked perfectly with our project that makes heavy use of JDOM everywhere. Passes all our tests (3000+, not all XML related, but most require reading and writing XML files). For a smoke test, everything worked alright.

hunterhacker commented 2 years ago

I marked the 2.0.6.1 bundle as released on oss.sonatype.org.

chadlwilson commented 2 years ago

Thank you @hunterhacker for persevering with this. Both I and the community appreciate it.

Couple of notes that might be relevant to folks

I'm finding it a little hard to figure out right now, possibly due to some merge noise in the history. It looks like this diff, but it's re-including a bunch of commits prior to the last Feb 2015 release, so perhaps some (non-harmful?) rebase issue happened somewhere along the way. Would be good to confirm the built commit in any case.

mprins commented 2 years ago

Please push the tag and update the site; As this project has not had any releases over the past years many will consider this dormant / dead and now @Dependabot and other tools start pushing for updates, but it is really hard to validate those updates without stumbling upon this still open issue...

tuxji commented 2 years ago

I would reiterate what @mprins said. Our Apache project got a scala-steward PR bumping jdom from 2.0.6 to 2.0.6.1 and I said this as my first comment:

-1

I have visited both http://www.jdom.org/ and https://github.com/hunterhacker/jdom/ and neither say anything about a JDOM 2.0.6.1 release. The GitHub repository has no new commits since October.

Even though I have found this issue, my last comment still says:

Let's wait for both the JDOM website and GitHub repository to be updated before bumping the jar. I have left a comment on their issue asking them to announce the 2.0.6.1 release on the JDOM website and upload the jar to their GitHub Release page so that no one else has to spend a lot of additional time checking the jar's validity.

eschulma commented 2 years ago

So the new version is on Sonatype but not here or Maven Central? How do we know that it is legit? As other have stated I see no new commits or releases here. I don't want to put a new version of a jar in my projects without a clear understanding of what has changed.

mprins commented 2 years ago

...n Sonatype but not here or Maven Central

oss.sonatype.org is a frontend to maven central, so sonatype == maven central

https://repo1.maven.org/maven2/org/jdom/jdom2/2.0.6.1/

also JDOM does hava a mailing list that announced this: https://jdom.markmail.org/search/?q=#query:+page:1+mid:rgi46abannimpdmy+state:results

hunterhacker commented 2 years ago

It’s legit, but please test the heck out of it. I’m coming in cold here. That’s why I didn’t make a big splash. People who have been pushing hard for this release and watching the issues can now go test. If no problems, we’ll spread the word.

eschulma commented 2 years ago

Is there a way for us to see the relevant commits?

hunterhacker commented 2 years ago

Tagged the release to help there.

chadlwilson commented 2 years ago

Thanks for tagging the release @hunterhacker .

Given the commits there, IMHO it probably should have been released as 2.0.7 or 2.1.0 since it includes other changes/enhancements (even ignoring test and typo/docs fixes). 2.0.6.1 would probably have been more appropriate for a cherry-picked release off a new branch based on @eneklo 's approach.

Change Review

To assess this for my own use, I tried to look through everything I could. The below is

Changes

Bugs fixed

Dependency changes

Summary

The mess in the commit diff seems to come from #190 which seems to have been done so the project could release off master rather than the jdom-2.0.x branch, and there are rebased commits. e.g original and rewritten which were in 2.0.6 but show up again in the latest tag.

My inference so far is that if you don't use StAX this is probably lower risk as an upgrade for you. I haven't assessed whether the changes affect existing StAX support or are pure add-ons, so they may also be low risk, but you might want to take a look.

This does not constitute security advice on my part, yada yada - but hope that helps others, and feel free to let me know if I have missed something.

steinarb commented 2 years ago

2.6.0.1 still gives this security warning https://nvd.nist.gov/vuln/detail/CVE-2021-33813

The warning is from something called "Nexus IQ".

Unfortunately I have no idea how to register a release as a fix for a CVE... but someone probably should do so...? :-)

albertus82 commented 2 years ago

@steinarb It seems to be an outdated warning. The CVE states: "Up to (including) 2.0.6". Probably we should wait a while.

eneklo commented 2 years ago

@chadlwilson I released a v2.0.6.2 version based on https://github.com/hunterhacker/jdom/issues/189#issuecomment-955682820. Those who are curious can find it here: https://github.com/eneklo/jdom/releases/tag/v2.0.6.2.

steinarb commented 2 years ago

The report I got mentioned 2.6.0.1 and I interpreted the warning saying 2.6.0.1 was having the issue.

The wording of the warning was:

Security-High
--
  | org.jdom : jdom2 : 2.0.6.1
  | CVSS >=7 and <10
  | Found security vulnerability CVE-2021-33813 with severity >= 7 (severity = 7.5)
  | Found security vulnerability CVE-2021-33813 with severity < 10 (severity = 7.5)
  | Found security vulnerability CVE-2021-33813 with status 'Open', not 'Not Applicable'
albertus82 commented 2 years ago

@steinarb Weird... the Nexus IQ report should clarify the origin of the vulnerability, but consider that even Snyk has not yet detected v2.6.0.1: https://snyk.io/vuln/maven:org.jdom:jdom2

chadlwilson commented 2 years ago

I wonder if it's possible that adding a suffix of .1 is insufficient for some tools to consider it a different version when the prior release doesn't have a matching .0 at the end. That might be considered indeterminate.

Alternatively, Snyk doesn't consider any version fixed right now based on vulnerable versions being listed as versions [0,]. Possibly they require manual review/confirmation. If the latest version of software at time of CVE is known to be vulnerable, there's not really a reason to automatically assume that the next version released actually fixes any given vulnerability, without manual review/checking. Perhaps that's what they do in such cases.

The fact that this ticket is not closed yet possibly won't help either.

OWASP Dependency Check, based on NVD/NIST data does seem to automatically consider 2.0.6.1 as fixed though.

Vulnerable

jdom2-2.0.6.jar | cpe:2.3:a:jdom:jdom:2.0.6:*:*:*:*:*:*:* | pkg:maven/org.jdom/jdom2@2.0.6 | HIGH | CVE-2021-33813

OK

jdom2-2.0.6.1.jar | cpe:2.3:a:jdom:jdom:2.0.6.1:*:*:*:*:*:*:* | pkg:maven/org.jdom/jdom2@2.0.6.1 | | |
albertus82 commented 2 years ago

Now Snyk reports v2.0.6.1 as NOT vulnerable.

ottlinger commented 2 years ago

Any plans to have a release to Maven central? Thanks

jamesagnew commented 2 years ago

@ottlinger the 2.0.6.1 release shows up on maven central for me: https://search.maven.org/artifact/org.jdom/jdom2/2.0.6.1/jar

ottlinger commented 2 years ago

@jamesagnew not sure how long a sync takes, but https://mvnrepository.com/artifact/org.jdom/jdom does not show the newest version yet and I'm unable to fetch with Maven default settings:

[ERROR] Failed to execute goal on project apache-whisker-xml: Could not resolve dependencies for project org.apache.creadur.whisker:apache-whisker-xml:jar:0.2-SNAPSHOT: Could not find artifact org.jdom:jdom:jar:2.0.6.1 in central (https://repo.maven.apache.org/maven2) -> [Help 1]
[ERROR]
chadlwilson commented 2 years ago

@ottlinger Thats because you are looking at the wrong artifact. https://mvnrepository.com/artifact/org.jdom/jdom2

mmkamburova commented 2 years ago

Hello,

Are there any plans to port the fix for CVE-2021-33813 to jdom v1.x? We're experiencing issues with Apache Commons JXPath, which is not compatible with jdom v2.x..

steinarb commented 2 years ago

FWIW the maven-release-plugin still uses JDom v1 (which may cause some strange line ending issues during release https://issues.apache.org/jira/browse/MRELEASE-1025 )

(But maven-release-plugin would IMO be better off replacing JDom 1 with JDom 2, rather than getting a JDom 1 with the security issue fixed... since that would make it possible to fix MRELEASE-1025)

hunterhacker commented 2 years ago

No current plans. If you're worried about entity expansion, call builder.setExpandEntities(false).

The only actual concern is if you (a) intend not to expand entities, (b) don't use the explicit JDOM flag to turn this off but instead (c) directly tell the underlying parser to turn them off, so then (d) you're surprised that your call to the parser didn't apply because JDOM supersedes your complex direct call with its own simple explicit flag setting.

The challenge is once the CVE is out there things are tainted up the chain. I recognize that. And sigh, maybe you can convince me it's worth a chunk of my time. I should really charge support for fixing bugs in software I released 10+ years ago. "The first 10 years are free!" :)

mmkamburova commented 2 years ago

Thanks, @hunterhacker! Well v1.1.3 was released Feb, 2012, so we have some time before the support becomes paid :) Anyway, I understand your point of view! We're in position where we need to provide a fix for the older releases of our product. Our product is a shared product, which main purpose is to deliver third-party libraries at a shared location. Then the rest of the products in our company use these third-party libraries from that location. And part of our job is to take care of vulnerable libraries by updating them to safer versions. The actual problem here are the transitive dependencies. In older releases, our products use some old third-party libraries, like Apache JXPath, Apache Velocity and who knows what else, which require the org.jdom package: "org.apache.velocity 1.5.0.v201212051755) requires 'java.package; org.jdom [1.0.0,2.0.0)' but it could not be found" In order to port a fix with jdom update from v1.x to v2.x, these products need to do a lot of changes in order to consume Jdom v2.x. Currently we're still struggling with Apache Velocity migration from v1.x to v2.x...

Sorry to bother you again and sorry for taking some of your time! If it's not a lot of work to backport the fix to v1.x, would you consider doing it?

Thanks & Regards, Maria

steinarb commented 2 years ago

NexusIQ now have the following possible mitigation on its JDOM2 2.0.6 critical warning:

Upgrade to 2.0.6.1
Next version with no policy violation

I.e. this issue is now fixed as far as NexusIQ is concerned.

Nriver commented 2 years ago

It's almost a year passed since the issue started. Wonder if there will be a formal release or not.

chadlwilson commented 2 years ago

@Nriver There is a formal release - 2.0.6.1 (this one). This issue would ideally be closed now to add a bit more clarity to that.

steinarb commented 2 years ago

@chadlwilson I opened this issue, and I'm good with closing this as fixed by 2.0.6.1 now (in case someone was waiting for my input?)

Nriver commented 2 years ago

@Nriver There is a formal release - 2.0.6.1 (this one). This issue would ideally be closed now to add a bit more clarity to that.

Thank you！

jacalata commented 2 years ago

Summing up this thread

@hunterhacker could you close this one please? :)

javanobugs commented 2 years ago

because sorry,I used the wrong coordinates。right:jdom2

i also met

noorharees commented 1 year ago

image

I am Integrating fro jDOM1.X to JDOM2:2.0.6.1

vmassol commented 1 year ago

About:

if the consuming code makes no attempt to call setFeature("http://xml.org/sax/features/external-general-entities", false) or setExpandEntities(false) then they have a potential XXE attack problem regardless of this CVE (depending on how they receive+use XML documents) making the CVE irrelevant.

@chadlwilson Thanks for trying to summarize it! However, does it mean that https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#saxbuilder is not correct when explaining that doing the following is enough to protect from XXE attacks:

SAXBuilder builder = new SAXBuilder();
builder.setFeature("http://apache.org/xml/features/disallow-doctype-decl",true);
Document doc = builder.build(new File(fileName));

This code doesn't use either setFeature("http://xml.org/sax/features/external-general-entities", false) nor setExpandEntities(false) and yet is supposed to be safe from XXE attacks.

Thanks

chadlwilson commented 1 year ago

@vmassol It looks like that change was made 4 months ago in https://github.com/OWASP/CheatSheetSeries/commit/c63fdaf34344a0d27df11bba92d92218d6cf2b72 as part of https://github.com/OWASP/CheatSheetSeries/issues/966 so you might want to take it up over there in OWASP land.

Before Feb 2023 it used to look like https://github.com/OWASP/CheatSheetSeries/blob/ef4beb83b59d474d02ec05afa7d79efe554dc3e8/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.md#saxbuilder which is rather different.

vmassol commented 1 year ago

@chadlwilson good point, thanks for your reply!

What they wrote is probably right but it would have been nice to get a confirmation from one of the devs of JDOM2 (I'd expect that before writing the instructions they validated them with the JDOM2 project).