Backports of CVE-2017-7525

[Michael Yoder]

TL;DR: I've backported the fixes for CVE-2017-7525 and related issues to select old / archaic versions. This might be useful to someone else, hence this email.

Cloudera (my employer) provides supported versions of lots of open source projects.  Most of them use jackson in some form.  Most of them also use an outdated version of jackson.  We can't easily upgrade the jackson versions due to concerns of backwards compatibility (real or imagined). (Major releases, where we have freedom to upgrade stuff, are few and far between.) This puts us in a tight spot sometimes, particularly with security vulnerabilities.

Enter CVE-2017-7525 (and related CVEs:  CVE-2017-15095, CVE-2017-17485, CVE-2018-5968, and CVE-2018-7489).  I understand that the maintainers don't want to patch every version of jackson, which is understandable. I also understand (thanks to Cowtowncoder's blog post) that actually hitting this vulnerability is rare and relatively easily detectable. One might think that I could review all our code and determine if we're ultimately vulnerable. There are some problems with this, however.

1. New, future code could be written that is vulnerable
2. Some third party code could use jackson and be vulnerable, and we wouldn't know it.  (Who knows what Spring does with jackson?  I sure don't.)
3. Customers might demand that we get this vulnerability off their security dashboard.  (Yes, this happens.)

So, what to do?  I can't upgrade to 2.9.5 and be done with it.  Shoot, lots of stuff is still using 1.8 or 1.9.  I can't argue that we're actually not vulnerable. So that leaves the one horrible option of forking jackson, backporting the fixes for these CVEs, and maintaining that fork.  Here you go:

https://github.com/cloudera/jackson

https://github.com/cloudera/jackson-databind

Look for branches ending in "cloudera" in both of those repositories.  You'll find branches for 1.8.10, 1.9.13 (in the former), 2.1.0, 2.2.2, 2.2.3, 2.3.1, 2.6.2, 2.6.3, and 2.6.5 (in the latter).  In addition, these are published to our maven repo, for example at

https://repository.cloudera.com/artifactory/libs-staging-local/org/codehaus/jackson/jackson-mapper-asl/

https://repository.cloudera.com/artifactory/libs-staging-local/com/fasterxml/jackson/core/jackson-databind/

Note the "-cloudera.1" version strings.

Licensing-wise, this is of course all under the ASF (even though there is no new IP, just backports, the lawyers got involved to make it official) so feel free to use as you see fit.  

In closing, two humble requests:

1. If there are more security-related fixes for this class of vulnerability, I'd love to know about them ahead of time, if possible.
2. I've noticed that reporting and discussion of security vulnerabilities happens out in the open in github issues. While useful if you're a white hat, this approach does have the problem that attackers can see the vulnerability before a release with the fix has been issued. I'd like to recommend the Apache approach to security vulnerabilities instead.

Regards,

-Mike Yoder

Cloudera, Inc

[Tatu Saloranta]

This sounds like useful for many users. Thank you for sharing!

Some thoughts....

On 1.x; there is:

https://github.com/FasterXML/jackson-1

from which it would be nice to still release 1.9.14. But as things
are, there is no Maven release process into Nexus
that works (1.x uses/used Ant, with ant-maven plugin, which may or may
not work and that required bit of manual wrangling with gpg signing).
The main complication for Mavenification was, I think, challenge of
producing 2 jars (-asl, -lgpl). But at this point I think I'd be fine
with just -asl variant.

On security-related fixes, I added tag `CVE` in github for
jackson-databind. That might make it easier to see security work.

There's blog article on vulnerability (all of CVEs, aside from earlier
XML ones, are for just one specific attack, just using different
gadget classes):

https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062

I have also suggested that perhaps there should be jackson-security
mailing list, which would not be archived, and would require approval
for joining -- this would make it possible to discuss security issues
before fix. If anyone has suggestions on good way to go about this
(that is, I can se up mailing list / group, but I have not managed
security-related ones and assume there are things I should know), I
would love to hear.

As to existing discussions: I only add details after merging fixes,
but this does occur before releases. I am not sure what would be good
way to go about this -- I assume separate bug tracker, with visibility
restrictions would be the way to go. Similar to closed mailing list?

-+ Tatu +-

> --
> You received this message because you are subscribed to the Google Groups
> "jackson-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jackson-user...@googlegroups.com.
> To post to this group, send email to jackso...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Michael Yoder]

On Wed, Apr 4, 2018 at 6:30 PM, Tatu Saloranta <ta...@fasterxml.com> wrote:

This sounds like useful for many users. Thank you for sharing!

You're welcome. 

Some thoughts....

On 1.x; there is:

  https://github.com/FasterXML/jackson-1

Oh, I didn't realize that. I forked from codehaus/jackson; did I miss any commits?

 

from which it would be nice to still release 1.9.14. But as things
are, there is no Maven release process into Nexus
that works (1.x uses/used Ant, with ant-maven plugin, which may or may
not work and that required bit of manual wrangling with gpg signing).

I fiddled with that for awhile, didn't get anywhere (I'm not all that experienced with ant-maven), and took a different route.  Actually, kinda hit it with a hammer - a script that does a direct push with curl:

https://github.com/cloudera/jackson/blob/jackson-databind-1.9.13-cloudera/bin/deploy-mapper-asl.sh

No one outside cloudera could use it, since it's got cloudera-internal links, but you get the idea. It's also jackson-mapper-asl only.

 

The main complication for Mavenification was, I think, challenge of
producing 2 jars (-asl, -lgpl). But at this point I think I'd be fine
with just -asl variant.

On security-related fixes, I added tag `CVE` in github for
jackson-databind. That might make it easier to see security work.

There's blog article on vulnerability (all of CVEs, aside from earlier
XML ones, are for just one specific attack, just using different
gadget classes):

https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062

I did see this, it was *quite* helpful. 

I have also suggested that perhaps there should be jackson-security
mailing list, which would not be archived, and would require approval
for joining -- this would make it possible to discuss security issues
before fix. If anyone has suggestions on good way to go about this
(that is, I can se up mailing list / group, but I have not managed
security-related ones and assume there are things I should know), I
would love to hear.

It works pretty much like you'd imagine - a closed mail list, trusted committers on it, etc.  Typically named "security@<project>.apache.org", in your case I'd imagine something like "jackson-...@googlegroups.com"

As to existing discussions: I only add details after merging fixes,
but this does occur before releases. I am not sure what would be good
way to go about this -- I assume separate bug tracker, with visibility
restrictions would be the way to go. Similar to closed mailing list?

 The Apache algorithm for CVEs is, essentially,

• Someone reports something bad (via email to the security list)
• Acquire a CVE number
• Fix the issue, but in a non-obvious manner. Sometimes this means mixing it in with another fix, a non-descriptive commit message, etc
• Release
• Announce to the world that there's a CVE, the vulnerability, and that they better upgrade.

I've never heard of using a separate bug tracker. Typically all the vulnerability discussion happens on the security mailing list. It's low-volume enough that you can get away without a separate jira instance or anything.

-Mike

[Tatu Saloranta]

On Wed, Apr 4, 2018 at 9:43 PM, 'Michael Yoder' via jackson-user
<jackso...@googlegroups.com> wrote:
> On Wed, Apr 4, 2018 at 6:30 PM, Tatu Saloranta <ta...@fasterxml.com> wrote:
>>
>> This sounds like useful for many users. Thank you for sharing!
>
>
> You're welcome.
>
>> Some thoughts....
>>
>> On 1.x; there is:
>>
>> https://github.com/FasterXML/jackson-1
>
>
> Oh, I didn't realize that. I forked from codehaus/jackson; did I miss any commits?

I think there was some confusion earlier, when Codehaus shut down so
that didn't help.
There have been couple of patches there, but not a ton.

>>
>> from which it would be nice to still release 1.9.14. But as things
>> are, there is no Maven release process into Nexus
>> that works (1.x uses/used Ant, with ant-maven plugin, which may or may
>> not work and that required bit of manual wrangling with gpg signing).
>
>
> I fiddled with that for awhile, didn't get anywhere (I'm not all that
> experienced with ant-maven), and took a different route. Actually, kinda
> hit it with a hammer - a script that does a direct push with curl:
>
> https://github.com/cloudera/jackson/blob/jackson-databind-1.9.13-cloudera/bin/deploy-mapper-asl.sh
>
> No one outside cloudera could use it, since it's got cloudera-internal
> links, but you get the idea. It's also jackson-mapper-asl only.

Ok. Yeah, if that was trivially easy to solve, it would already have I'm sure :)
(not just by me but by others, I know this is sort of widely-wished-for thing)

>
>>
>> The main complication for Mavenification was, I think, challenge of
>> producing 2 jars (-asl, -lgpl). But at this point I think I'd be fine
>> with just -asl variant.
>>
>> On security-related fixes, I added tag `CVE` in github for
>> jackson-databind. That might make it easier to see security work.
>>
>> There's blog article on vulnerability (all of CVEs, aside from earlier
>> XML ones, are for just one specific attack, just using different
>> gadget classes):
>>
>>
>> https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062
>
>
> I did see this, it was *quite* helpful.

Ok good. I wrote it as I didn't see in-depth explanations. And since
it's not trivially easy to understand
due to many reasons. Not the least because Default Typing is kind of
esoteric feature.

>> I have also suggested that perhaps there should be jackson-security
>> mailing list, which would not be archived, and would require approval
>> for joining -- this would make it possible to discuss security issues
>> before fix. If anyone has suggestions on good way to go about this
>> (that is, I can se up mailing list / group, but I have not managed
>> security-related ones and assume there are things I should know), I
>> would love to hear.
>
>
> It works pretty much like you'd imagine - a closed mail list, trusted
> committers on it, etc. Typically named "security@<project>.apache.org", in
> your case I'd imagine something like "jackson-...@googlegroups.com"

Yea, that would seem like the simplest approach.

>
>> As to existing discussions: I only add details after merging fixes,
>> but this does occur before releases. I am not sure what would be good
>> way to go about this -- I assume separate bug tracker, with visibility
>> restrictions would be the way to go. Similar to closed mailing list?
>
>
> The Apache algorithm for CVEs is, essentially,
>
> Someone reports something bad (via email to the security list)
> Acquire a CVE number
> Fix the issue, but in a non-obvious manner. Sometimes this means mixing it
> in with another fix, a non-descriptive commit message, etc
> Release
> Announce to the world that there's a CVE, the vulnerability, and that they
> better upgrade.
>
> I've never heard of using a separate bug tracker. Typically all the
> vulnerability discussion happens on the security mailing list. It's
> low-volume enough that you can get away without a separate jira instance or anything.

I like issue trackers, to a degree, but big part may be just for my own benefit.
Part of the problem is also that although it is possible to file an
CVE, that has its trade-offs;
on one hand, there is the whole ecosystem for downstream that gets
notified (plus side).
Downside that there seems to be little control over how things get
handled (at least to me it seems
like a black box), so it's maybe more a placeholder than useful for
storing anything about state.

Then again, if and when CVE entries are public, visibility isn't much
lower than for github issue entries.

-+ Tatu +-


>
> -Mike