Got security warning on JDom2 2.0.6: CVE-2021-33813
steinarb opened this issue · comments
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.
A pull request is already created: #188
If you call builder.setExpandEntities(false) then JDOM won't expand entities. The issue here is people may try to set this only via direct calls to the parser and not with the official JDOM solution (which takes precedence).
https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html
I intend to accept the pull request (doesn't hurt, small benefit) but I'm not sure I can push to Maven without either Rolf or a lot of trouble.
Any news on this? Did you accept the pull request and did you manage to push to maven?
I accepted. I don't have the maven credentials since that was Rolf's business.
Ok. Nice. So, when can we expect a release?
Maybe a non-maven for now?
@hunterhacker any idea on when we could see an official Maven release with this fix?
@hunterhacker Also interested in a Maven release date as soon as possible. Thanks!
@hunterhacker There are a lot of libs that ultimately depend on jdom2 and now every application that use one of them has CVE-2021-33813, so I hope that a Maven release will follow shortly. Thank you in advance.
@hunterhacker we are waiting for a maven release as well, thanks in advance!
Hope you can consider the super simple PR #185 as part of the release.
It would make things easier for projects targeting JDK17.
OK, folk, lots of catching up to do, a mail configuration SNAFU resulted in me missing notifications on JDOM for a while, and I have to collect some content together to push this through (and obviously work to ensure I am not a single point of failure on this process).
Please be patient while I work though all the checks/balances, and ensure all the parts align before pushing a new release.
Right, merged to master all the changes in the backlog, including a number of fixes and test case changes related to this issue.
Going to get back at this in the next day - will need to address some other issues before releasing a new build still.
Another ten days later still no release.
What are your plans concerning the release of the security fix?
when can we expect a release with this security fix??
I am interested in an update with this security fix as well. Any indication when a release could be coming?
I am also interested in this security fix. When this fix will be released?
I've been waiting for @rolfl to step in here. I'm not exactly sure why he's not. Another email snafu? I tried pinging him privately.
Meanwhile, if you're looking at this issue and are worried about the risks of expanding entities, call the nicely named function setExpandEntities(false) which turns off expanding entities. That always works perfectly.
It's important to note the PR doesn't change any default behaviors. Entities still expand by default. The PR only changes what happens when you don't call the nicely named function but instead talk to the underlying parser directly by setting the obscurely named "http://xml.org/sax/features/external-general-entities" feature to false. If that's what your code does, then might I suggest you change your code to use the nicely named function as well.
I recognize once there's a CVE people want an update. I'm just pointing out the update won't change default behaviors and will only improve the behavior of code that has a calling pattern that isn't robust.
Thanks for helping out @hunterhacker.
To me, it seems the linking of the CVE here, and its current generic description (arguably a bit alarmist?) is creating a slightly misleading impression to folks who are seeing this pop up (possibly from a transitive dependency) that a fix in the library is the only thing required to magically close off a possible XXE attack for people's system.
In reality it seems all the fix does is make the library act according to "principle of least surprise" if a consumer followed the earlier OWASP generic recommendation (prior to this commit) or was doing the generic SAX thing via setFeature.
So the library never prevented anyone from blocking off XXE. One just needed to do it via the setExpandEntities route, not the setFeature route.
So it's a little confusing to me. Seems the earlier OWASP recommendation wasn't tested/verified!? setFeature does have quite a disclaimer also:
jdom/core/src/java/org/jdom2/input/SAXBuilder.java
Lines 778 to 783 in 03a391a
If I read correctly, the current plan/merged PR is still dependent on people disabling the functionality with either the builder or the setFeature route, as it doesn't change the behaviour to "secure by default" which would cut off the vulnerability for those who are consuming JDOM transitively via another library. That library would have to have been following the earlier OWASP recommendation in its code, and the behaviour will change. So direct consumers still need to review their code and usages of SAXBuilder, and some of them may not have been doing anything to disable XXE at all in the first place.
My broad summary (please correct me if I am wrong) is
- if the consuming code makes no attempt to call
setFeature("http://xml.org/sax/features/external-general-entities", false)orsetExpandEntities(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. - if the consuming code already called
setExpandEntities(false)in relevant places, then they are not affected by this CVE and can safely suppress it. - if the consuming code already called
setFeature("http://xml.org/sax/features/external-general-entities", false)on its own and expected it to be enough to protect them, then the fix in #188 will magically fix it for them without code change; however they still have the ability to resolve it withsetExpandEntities(false)right now.
Am I missing something? I am curious how many real world usages are in the #3 group.
Nevertheless, if we look at this CVE more as
setFeatureshould work as expected to disable entity expansion
with the broad class of
unintentional security misconfiguration possibly allows unintended XXE
that would seem more accurate to me than
An XXE issue in SAXBuilder in JDOM through 2.0.6 allows attackers to cause a denial of service via a crafted HTTP request
... which does not seem an accurate description of the problem to me, and assumes specific usage context.
@chadlwilson This still doesn't change the fact that (A) the CVE was published over a month ago and (B) the commit fixing the issue (if I am not mistaken) has been there since February and (C) nothing seems to have happened since.
So while I do agree that this fix is not a silver bullet for avoiding XXE, I'm still itchy about how this project handles the issue. They could have just thrown out a half-baked 2.0.6.1 as 2.0.6 + PR#188 advertised as such with just the fix, and do whatever they are doing now for a more polished 2.0.7. So people interested in not having this showing up in their vulnerability scanner could just switch to 2.0.6.1, all other can wait for 2.0.7.
@j-be To be fair, commits were merged a few weeks ago, so that's not "nothing", however It's a bit odd that a quick release hasn't been cut after, I agree. Since the project has had basically no development for over 6 years it seems (as measured by releases), any signs of life are better than nothing.
Nevertheless, the attribution and description of the CVE in this case is a bit dubious IMO. It has created a lot of noise here, amplified by it being on a mature, but old library that is still a common dependency deep down inside a lot of Java software. I feel some more active/mature projects might have had cause to dispute some aspects of the CVE, however no CVE can be looked at blindly without taking into consideration the context of the software's usage. To me, this means context-dependent suppression is a reality of life.
While I agree that it is impossible to assess all ones transitive dependencies, and vulnerability scanner noise is annoying (it's what lead me here also), it doesn't help make our systems more secure to have (what seems to me to be) FUD out there in CVE descriptions and their linked CWE. Let's say a new version is released. I upgrade. The noise goes away, but am I any more secure? Quite likely not. Might make us feel better, but that's not the same as being more secure.
If you don't have the inclination to dig yourself, one suggestion I would have is to look at the next most immediate consuming dependency(ies?) up your chain, and ask for them to assess whether that library is actually vulnerable in its usage of jdom. If not, you can probably suppress and move on. If so, they can follow the suggestions above to mitigate, and then can suppress?
@chadlwilson I agree with most of what you say. But I have to disagree on the "am I more secure".
What I (average developer) tend to do if something pops up on the scanner is: does the update break anything? If not: upgrade. I don't even care about what is or was affected, and if and how it could be exploited in our specific software. As long as a patched version is available and doesn't break anything I upgrade - no questions asked. In the end: chances are I don't even grasp if and how and what the security implications are when directly using a library, leave aside having to check umpteen layers of transitive dependencies for potentially exploitable situations.
The average developer may not even be able to determine this, either because of skill, or simply because assessment means sinking a lot of time into evaluating the issue. Changing a version in pom.xml or build.gradle is done in seconds. If you have a security department in your company it is a different story. But truth is: some of us simply don't. So for some of us the scanners and timely patches is all we have.
With all of this: "Am I more secure?" I'd say "Hell yeah" - not for every individual case, but in long term for sure. I personally simply don't have the time, and for some not even the skill to assess every single vulnerability. And underestimating a single one may be Game Over.
Well, you are taking my words rather out of context by applying them generally, rather than to this specific case as I articulated, so that's not really fair. As a general rule, upgrade first, ask questions later makes sense. I spoke about this specific case, and indicated that maybe it does not.
I did explicitly say "it is impossible to assess all ones transitive dependencies" the equivalent as you, and I also approach upgrading this way. I was just trying to help others, by synthesising what I read across the place, and indicating that in this specific case, it may not affect them if their direct usage is a particular style, and that chasing the devs here because a 3rd party reported a security vulnerability on the basis of "THERE'S A CVE FIX IT FIX IT" and asking them to make the noise go away even if it does little doesn't appear very fair.
Software and supply chain complexity is a big problem for users for sure. It relies on each layer in the chain to be able to translate context to the layer above; to avoid using dead/deprecated dependencies and migrate away; to keep being maintained have have an easy+regular patch process. We don't appear to have a sufficient way of keeping on top of that complexity right now. We have these scanners that cut through the layers, say "oh you have jdom here" and then present users with information that they often don't have the expertise to judge (security department or not) because they are working with a higher level abstraction. They all arrive on Github on the deepest dependency going "fix it fix it", and the middle tiers that actually use that dependency, have necessary context, and may already have a mitigation in place aren't always interrogated for the necessary context. Just reflecting that it doesn't seem to help us very much as either "don't want to go deeper" users of a transitive dependency or "direct" users, who have control of the code to have vagueness in vuln descriptions.
@chadlwilson Sorry, I actually understood your statement as "generally" - my bad.
But for this specific case I still hold up my criticism: if other libraries use jdom's setFeature("http://xml.org/sax/features/external-general-entities", false) rather than setExpandEntities(false) they are well within spec, and should be safe.
Furthermore, the OWASP recommendation does that as well. It seems only because of http://apache.org/xml/features/disallow-doctype-decl, false that piece of code is not affected - as long as Xerces 2 is used under the hood that is.
Hence, I would not consider this "noise". It may not affect everybody here - I for one am pretty sure by now I am not. But I still want this fixed asap, as I may be affected tomorrow without knowing it (think new dependency comes in, Bob the intern parses XML, stuff like that), or I may be simply wrong and I am affected after all.
We could of course hunt down every single library using jdom the vulnerable way and patch all of those. And I'm not saying that is a bad idea: every additional layer helps. But the root cause for this is jdom not behaving to spec, not other libraries using jdom the wrong way - that is a different topic all together.
So as far as I am concerned: count me in on the "THERE'S A CVE FIX IT FIX IT": It is a vulnerability (no doubt about that), an exploit is possible (I don't mean to say likely, but that is not even my point), so it needs to be fixed. Now. Period.
Any update here?
Any update here?
Ditto. https://issues.apache.org/jira/browse/TIKA-3506
Many, many thanks for jdom2!
Thanks for the hard work on this one JDOM team!
I have read the comments and have learned some things.
Like the others, I would appreciate it very much if the fix would released to Maven,
Does anyone work at IBM who could ping Rolf Lear there and check why he came back and then left?
Really appreciate the hard work JDOM team! If you have time please release it to maven as we are waiting for it. Thanks in advance!
@hunterhacker Thank you for the update on this. We are also impacted by the issue hence would appreciate a Maven release as soon as possible. Thanks!
We are also impacted by this issue when can we expect a maven release.. Thanks !
This is crazy.
Any update?
Any update on the release?
Did anyone working at IBM reach out to Rolf?
a few things...
- The base issue is not an issue - turning off entity expansion is as simple as setting
builder.setExpandEntities(false)(As Jason mentioned here: #189 (comment) there's no need for the new/redundant mechanism.... the current code is JUST FINE, and works as documented, etc... The "fix" that has been proposed is not fixing anything that was broken before, it's just doing the same thing the code can already do, but in a more buggy way (some odd interactions can happen with validation, etc.) - I am struggling to get an old version of Java to get the code built to the right compatibility levels (code compatibility, etc.) (ensuring the new version of the built library works with Java 1.5 is required unless we change the base compatibility statements)
- I need to update the whole mechanism for uploading code to the oss.sonatype system with new certificates, etc.
The above stuff is going to take a number of days to sort out what to do, whether to put out a new JDOM 3.x with different Java version compatibility, etc? Also, it will take a bunch of time to sort out the certificates, and understand how the new release process should work with oss.sonatype
Given other factors, I have simply not had the full stretches of time available to sort out all these issues.... yes, it looks like just a few days work to get it done, but there will need to be a bunch of considerations that need to be agreed on ahead of time, and I have simply not had time (for personal reasons) to get that all done. .... and yes, some of those personal reasons have meant that I have not even had internet connections for long stretches of time (social distancing in the wilderness of Canada for summer holidays is a good thing.... ).
So, there's no real urgency to this PR since, as Json mentioned, the "fix" that this PR applies is EXACTLY what setExpandEntities(false) does :
The base issue is not an issue - turning off entity expansion is as simple as setting builder.setExpandEntities(false) (As Jason mentioned here: Got security warning on JDom2 2.0.6: CVE-2021-33813 #189 (comment) there's no need for the new/redundant mechanism.... the current code is JUST FINE
That's not true, imho. Apart from the official JDOM proprietary API with setExpandedEntity(...), JDom is also supporting the official way of configuring the underlying SaxParser using SaxBuilder.setFeature(..).
A developer using saxBuilder.setFeature("http://xml.org/sax/features/external-general-entities", false) should safely assume, that this call does what it is expected to do. BUT IT DOES NOT.
This is the BUG you should fix since months now.
If you think, that saxBuilder.setFeature("http://xml.org/sax/features/external-general-entities", false) should not be used at all with JDOM, then deprecate/remove that API from JDOM or at least state it clearly in the Docs (which wouldn't solve any of the existing code using the API today of course).
I am very aware of the fact, that you do not get paid for this kind of work and that you are trying to do your best to further maintain the project. But if you state, that "this is not a bug", simply because you are not able to deliver the fix, then there is really something wrong.
Trying to understand your comment schlm3 - note the base issue is that expanding entities is a security risk. I get that. The stated and accepted resolution for all parties as I can tell, is to turn off entity expansion.
JDOM's documentation is clear that the right way to do that is to call setExpandEntity(false) - which does set the sax feature, but it also does MORE than that - turning off just that feature has side effects that need to be accounted for when parsing.
Setting features on the underlying SAX parser directly is supported with the setFeature function, yes, but the documentation also clearly states http://www.jdom.org/docs/apidocs/org/jdom2/input/SAXBuilder.html#setFeature(java.lang.String,%20boolean) :
NOTE: SAXBuilder requires that some particular features of the SAX parser be set up in certain ways for it to work properly. The list of such features may change in the future. Therefore, the use of this method may cause parsing to break, and even if it doesn't break anything today it might break parsing in a future JDOM version, because what JDOM parsers require may change over time. Use with caution.
So, a developer using setFeature(...) cannot safely assume the call does what is expected. That function exposes the internals of the sax parser in a dangerous way, and is documented that way.
Now, I agree that it is preferable that setting the feature does the same as setExpandEntities(false), and that it does not do the same as that call, BUT, even if it did the same, it would still be the WRONG way to do it using JDOM.
The right JDOM way to resolve the security issue is to use setExpandedEntities(...) ..... and yes, the setFeature(...) option should be a reliable backup, but the priority for this is thus lower.
I am not saying that this bug does not exist, I am saying that the correct way to address the security vulnerability is to use the existing, documented, and reliable way to turn off entity expansion.
The dangerous, setFeature() way will be fixed too... just not as urgently.
Note that on a personal level, when this issue came through, I was in the process of winding up my previous employment at IBM, and I am now employed elsewhere. I was not in a position where I could spend days trying to recreate and validate a build environment that produces JAR files compatible with Java 1.5 and later. I am still not there in my new job - I have commitments that are hard to put aside to spend days trying to build code that already works, when used as documented.
If you are desperate to use the not-recommended way to set the feature, the code in the repo does things in the right order now, and just needs to be built in an environment where it still passes all the test cases in Java 1.5, and in the android build environments. If you could help document how to locate the right Java SDK's and recreate build steps to get it validated on android, that would save me a bunch of time.
Dear Rolf,
Thank you for your detailed explanation. That really explains a lot to me.
I am pretty sure, that the quoted "NOTE" (from the setFeature() documentation) is indeed not clear enough to most developers using that API. I mean, how should a developer which uses that API know which features are not save to use with this method? If all features are not save to use, why do you still provide that setFeature() method? Why isn't it deprecated?
To be clear: all of our own, internal code uses JDom in the save way (not using setFeature(..), but setExpandEnities(false)). But as @j-be stated before, I can not speak for third-party libraries code. So our next library update which uses JDom transitively might come with the vulnerable configuration in it as long as JDOM does not fix this and delivers the update to maven.
Concerning your personal situation, I can totally understand that. I just had the impression, that you do not take the issue serious.
Concerning backward compatibility, is there really someone still using Java 1.5 ?
Unfortunately, I do not have any experience with Java for Android.
@eschulma Not actually true, see here. It is really easy to overlook though and I, too, did not see it as I wrote my comment a few weeks ago.
Anyway, I still think, that if everybody thinks supporting saxBuilder.setFeature("http://xml.org/sax/features/external-general-entities", false) is a good idea, so should JDom2.
If not, I'd propose to throw an IllegalArgumentException, or something like that if someone tries to use it anyway. On this things imho. its better to be safe than sorry.
And as @schlm3 I really doubt 1.5 is still worth supporting. Imho. even 7 is questionable, 8 is as far as I'd ever go.
To ensure compatibility with JRE 6, the new --release flag of javac might be enough: http://openjdk.java.net/jeps/247 (available in JDK 9+). Unfortunately the lowest supported target version is 6, not 5.
Still waiting for an official release. This can't be fixed in our code, as mentioned above, since it is used by other 3rd parties.
We are forced to remove this artifact from our production systems because this vulnerability has became too old and there is no fix released. Probably we will upload a fixed version to our internal Maven repository in order to keep temporarily our application in production, and then will consider how to opt out definitely.
I think we can consider this project abandoned; maybe someone else could take care of taking it forward, anyway thank you for the work done so far.
@eneklo Let's be supportive, I see commits from 10 days ago, this hardly seems abandoned. If you are going to make a private fixed version, why not open a pull request and benefit everyone.
@eschulma As far as I understood there is already a PR for this, i.e. #188, which has been merged quite a while ago. So as @rolfl already pointed out at the very end of his comment from a month ago, "releasing a fixed version" is equivalent to "build from master and deploy".
What I really don't understand, is why nobody from the project team does just that. A half-baked 2.0.6.1-jre8 release with Java 8 as minimum requirement and unknown Android support is most probably what 99% of people here are waiting for. Once that is done I for one do not care how long it takes to get the next "good" version for Java 5 and Android ready - because I think (Disclaimer: uneducated guess) very few people actually do.
Btw. if someone could express in more detail what is holding up the release from a technical perspective I am sure somebody here could step in and help.
So for all I am concerned, it could as well be, that the team is not able to publish new releases anymore - for whatever reason. And if that truly is the case, recent commits are imho. not a metric for how alive this project is.
Hi, I’m still here. Wave!
The challenge is Rolf handled all JDOM2 releases, and I don’t have the recipe or the credentials to push a new build out for Maven. I could, however, put a build on the JDOM.org website, if people would find that useful. Let me know.
Earlier in the thread Rolf explained how he wanted to be careful in doing the release so that doing a tiny (mostly cosmetic) fix here doesn’t cause issues with compatibilities that trip up people who will just blindly pull in the update via Maven.
It’s a real risk, and so while it’s true I could ask somewhere to get special access to the credentials and figure out the system he used to push it out, there’s definitely risk there it’ll break something. It’s more risk if I do than if he does, so I’d prefer if he did it, but he’s sure taking a long time now isn’t he. :)
Hi @hunterhacker, I just forked the project, created a branch named jdom-2.0.6.1 from the tag JDOM-2.0.6 and cherry picked the following 4 commits (I hope I included all the relevant ones):
I built using Apache Ant 1.9.16 and Oracle JDK 1.7.0_75 that is the same version used to build v2.0.6 which is on Maven Central; then I compared the resulting JAR with the one of v2.0.6: there is only one class file changed: SAXBuilder.class; I also compared SAXBuilder.java source with master and there are no code differences (only some fixed typos on master).
build.log attached.
Now, theoretically and obviously with your kind permission, I might sign the new artifact and upload it to Sonatype using my Group ID and the version 2.0.6.1, but I think that you could do the same thing avoiding a fork.
Thank you.
Sorry, but I honestly don't know what else to do to help unlock this situation.
Eneklo, how's it work when you do the "maven" ant target?
Rolf wrote up how he got things into Sonatype long ago for JDOM 1.x: https://github.com/hunterhacker/jdom/wiki/JDOM1.1.2-and-Maven
He wrote things up a bit more tersely for JDOM 2.x: https://github.com/hunterhacker/jdom/wiki/Build%26Release-process-for-JDOM
He's the only one who ever held the Sonatype account credentials. I've asked Sonatype if they might give them to me.
@hunterhacker BUILD SUCCESSFUL, see attached log. Obviously Ant asked my gpg passphrase to sign the artifacts.
The jdom2-2.0.6.1-maven-bundle.jar archive contains the following entries:
Archive: jdom2-2.0.6.1-maven-bundle.jar
Length Method Size Cmpr Date Time CRC-32 Name
-------- ------ ------- ---- ---------- ----- -------- ----
0 Stored 0 0% 08/11/2021 17:57 00000000 META-INF/
104 Defl:N 92 12% 08/11/2021 17:57 8a330166 META-INF/MANIFEST.MF
1008525 Defl:N 966572 4% 08/11/2021 17:57 ba0e3926 jdom2-2.0.6.1-javadoc.jar
673 Defl:N 534 21% 08/11/2021 17:57 e651ffba jdom2-2.0.6.1-javadoc.jar.asc
860244 Defl:N 821651 5% 08/11/2021 17:57 cb577fd1 jdom2-2.0.6.1-sources.jar
673 Defl:N 534 21% 08/11/2021 17:57 47ac281e jdom2-2.0.6.1-sources.jar.asc
304947 Defl:N 282442 7% 08/11/2021 17:57 f44bbbfb jdom2-2.0.6.1.jar
673 Defl:N 535 21% 08/11/2021 17:57 27792dbf jdom2-2.0.6.1.jar.asc
4600 Defl:N 1951 58% 08/11/2021 17:57 88e41643 jdom2-2.0.6.1.pom
673 Defl:N 533 21% 08/11/2021 17:57 63af86f9 jdom2-2.0.6.1.pom.asc
-------- ------- --- -------
2181112 2074844 5% 10 files
@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.
Is there any progress on this issue?
@eneklo, reach out to me at jhunter@servlets.com please. I'm curious why my test runs don't match yours.
Others can test http://jdom.org/dist/binary/jdom2-2.0.6.1-maven-bundle.jar in the meanwhile.
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.
I marked the 2.0.6.1 bundle as released on oss.sonatype.org.
Thank you @hunterhacker for persevering with this. Both I and the community appreciate it.
Couple of notes that might be relevant to folks
- the Jars don't have "consistent" versions in
META-INF/MANIFEST.MFandjdom-info.xml(currently2.x-2021.11.08.17.25). Likely won't affect most apps unless these files are loaded somehow at runtime I guess. - In lieu of a changelog, would you be able to create a tag/release against the commit it was built against so folks can easily see the diff and evaluate any weirdness for themselves?
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.
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...
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.
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.
...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
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.
Is there a way for us to see the relevant commits?
Tagged the release to help there.
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
- derived from brute force of this diff.
- reviewed each commit and associated pull requests to derive intent
- looked at the overall file-by-file diffs to distinguish signal from noise
- tried to cross reference to JAR diff as pushed to Maven Central
Changes
- Built with JDK
1.8.0_151-b12rather than JDK1.7.0_75-b13(still targets1.5usingsource/targetflags but probably explains some class/bytecode changes) - #105 and #119
StAXStreamReaderandStAXStreamWriterintroduced, originally seems intended for2.1according to JavaDoc (not sure why, commits are all from 2013 but not included in the2.0.6release.
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.
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...? :-)
@steinarb It seems to be an outdated warning. The CVE states: "Up to (including) 2.0.6". Probably we should wait a while.
@chadlwilson I released a v2.0.6.2 version based on #189 (comment). Those who are curious can find it here: https://github.com/eneklo/jdom/releases/tag/v2.0.6.2.
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'
@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
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 | | |
Now Snyk reports v2.0.6.1 as NOT vulnerable.
Any plans to have a release to Maven central? Thanks
@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
@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]
@ottlinger Thats because you are looking at the wrong artifact. https://mvnrepository.com/artifact/org.jdom/jdom2
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..
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)
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!" :)
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
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.
It's almost a year passed since the issue started. Wonder if there will be a formal release or not.
@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?)
Summing up this thread
- there are no plans to fix this CVE in JDOM 1.x, but I opened a separate issue to track that conversation (#204 )
- it is fixed (/mitigated) in JDOM2.0.6.1 and there is a formal release through Maven (https://mvnrepository.com/artifact/org.jdom/jdom2/2.0.6.1)
@hunterhacker could you close this one please? :)
because
sorry,I used the wrong coordinates。right:jdom2
i also met
I am Integrating fro jDOM1.X to JDOM2:2.0.6.1
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
@vmassol It looks like that change was made 4 months ago in OWASP/CheatSheetSeries@c63fdaf as part of OWASP/CheatSheetSeries#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.
@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).