CVE-2019-12814: Block yet another gadget type (jdom, CVE-2019-12814) · Issue #2341 · FasterXML/jackson-databind

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

Labels

CVE

Issues related to public CVEs (security vuln reports)

Comments

cowtowncoder changed the title Block yet another gadget type (CVE to be requested) Block yet another gadget type (CVE-2019-12814)

Jun 14, 2019

Fixed in 2.7, 2.8, 2.9, 2.10 and master branches for likely release in 2.9.9.1 and 2.10.0.

When can we expect a 2.9.9.1 release?

hilmarf, daniel-schel, victor7437, zageyiff, lbourdages, dannil, lbalmaceda, j-tim, jactor-rises, emmberk, and 37 more reacted with thumbs up emoji

This was referenced

Jun 22, 2019

I appreciate the hard work being done by the jackson-databind developers, but 3 days later, I have to repeat @antalindisguise’s question again: Why isn’t 2.9.9.1 released yet? Those of us who use the OWASP Dependency Check plugin in our projects now have failing builds because of CVE-2019-12814, without a proper remedy. I really don’t like adding a suppression for a legitimate security issue. 😕

@volkert-fastned if it helps, you’ve had a legitimate security issue for ages already, you just didn’t know about it until today. Plus, if you don’t have JDOM then it would be a legitimate suppression,

@OrangeDog Thanks. I read it in the CVE description as well.

So when the following commands return no results, the project should be unaffected, correct?

# Maven project
mvn dependency:tree | grep -i jdom

# Gradle project
./gradlew dependencies | grep -i jdom

@OrangeDog Thanks. I read it in the CVE description as well.

So when the following commands return no results, the project should be unaffected, correct?

# Maven project
mvn dependency:tree | grep -i jdom

# Gradle project
./gradlew dependencies | grep -i jdom

Well you would also have to “enableDefaultTyping” (either globally or for a specific property :)

For me, the problem is that our pipeline checks for dependencies with known issues and abort the process if a problem is found. You can argue that the problem is in the previous versions, but if the problem is solved why not just release?

@mpbalmeida in general you cannot expect every dependency to release a fix as soon as a vulnerability is known. If your pipeline relies on that, then you need to make changes.

@volkert-fastned

So when the following commands return no results, the project should be unaffected

What’s on the classpath when your code runs is not simply the list of project dependencies. You need to audit your systems and be aware of what’s happening.

We can manually trigger to rebuild, but I thought the problem was already solved because there were no open issues in 2.9.9.1 milestone

I don’t know the details of how this issue was discovered or originally disclosed (insert grain of salt)
But IMHO, It would be nice to release the fix before disclosing the vuln.

@volkert-fastned

So when the following commands return no results, the project should be unaffected

What’s on the classpath when your code runs is not simply the list of project dependencies. You need to audit your systems and be aware of what’s happening.

In the specific case of CVE-2019-12814, one of the prerequisites for being vulnerable (kind of a weird way to put it, but you know what I mean) is "the service has JDOM 1.x or 2.x jar in the classpath". Source: https://nvd.nist.gov/vuln/detail/CVE-2019-12814

By the way, it’s kind of odd how an XML dependency such as JDOM would trigger a JSON-related vulnerability.

@volkert-fastned if it helps, you’ve had a legitimate security issue for ages already, you just didn’t know about it until today. Plus, if you don’t have JDOM then it would be a legitimate suppression,

It is worth noting that JDOM2 comes as a dependency within the latest version of Spring-Boot-Starter-Parent 2.1.6
https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-parent/2.1.6.RELEASE
(edited to reflect a mistake i made by saying spring-boot when I meant spring-boot-starter-parent)
Thanks @benjamin Asbach for making me recheck and finding my mistake

If you run the cmd:
mvn help:effective-pom -Doutput=effective.xml
and then search for JDOM you can see it’s there at version <jdom2.version>2.0.6</jdom2.version>

Really hoping version 2.9.9.1 is released soon, this is causing me head aches.

It is worth noting that JDOM2 comes as a dependency within the latest version of SpringBoot 2.1.6

If you run the cmd:
mvn help:effective-pom -Doutput=effective.xml
and then search for JDOM you can see it’s there at version <jdom2.version>2.0.6</jdom2.version>

Really hoping version 2.9.9.1 is released soon, this is causing me head aches.

Really??? I thought mvn dependency:tree also showed all transitive dependencies. Yet another thing you can’t rely on. 😕

Thanks for sharing this method, @andr3w-hilton.

And again, not to be ungrateful to the developers, but what’s holding up the 2.9.9.1 release right now? Is it undergoing a final rigorous code audit and/or pentest? Because in that case, I completely understand and support the current holdup.

@volkert-fastned @cowtowncoder has simply taken a break lol - nothing more nothing less.
Perhaps assist by having a PR ready for when he gets back?

Well, to be fair, everybody deserves a good vacation every now and then. 🙂

But I don’t think any PRs are necessary anymore. The actual issues have already been resolved. It’s just that we’re still waiting for the 2.9.9.1 release that contains these fixes: https://github.com/FasterXML/jackson-databind/milestone/97

By the way, It’s somewhat worrisome how such a crucial library like jackson-databind apparently has so few developers maintaining it, that the vacation of one person would block a release with an important security fix. One obviously can’t blame any individual developers or maintainers for that. This is a problem that needs to be solved at an organizational level.

xD

Not really, usually all deploys are held monitored and approved by a single person?

There’s a few maintainers hey, I know Tatu is getting ready for 2.10 and doing the min jdk8 impl, i’m doing the jpms impl, I know a few others are doing a few bits as well.
Also what organization do you believe is running this project? :)

Naw, the way it is now is correct, the single point for final approve and deployment definitely is correct. and yea I think he is allowed a break for as long as needed. Rather wait patiently and get a refreshed mind doing it. There also seems to be people complaining about dropping jdk 6 support (but 2.10 drops jdk 7 support), so I believe there’s that consideration for 2.9.10 as well for some security fixes (although the jdk has more holes than any library), so there’s a lot going on

all deploys are held monitored and approved by a single person?

If (hopefully not) the one person who can do that gets hit by a car while on holiday, does that mean that there will never be another release of Jackson? There needs to be multiple people who can do it, both to deal with that situation, and with this one.

I thought mvn dependency:tree also showed all transitive dependencies.

It does. @andr3w-hilton is mistaken and looking at the <dependencyManagement> section, not the <dependencies>.

This was referenced

Feb 4, 2022

This was referenced

Mar 11, 2022

This was referenced

Mar 12, 2022

This was referenced

Mar 31, 2022

This was referenced

May 10, 2022

This was referenced

Apr 28, 2023

This was referenced

Aug 29, 2023

This was referenced

Sep 7, 2023

Labels

CVE

Issues related to public CVEs (security vuln reports)