[
https://issues.apache.org/jira/browse/CASSANDRA-14427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479994#comment-16479994
]
Lerh Chuan Low commented on CASSANDRA-14427:
--------------------------------------------
Hey [~jasobrown],
Sorry for the late reply, was overseas and then fell sick upon returning.
Thanks for looking at this ticket!!
Yep - the linked CVEs all reference Jackson databind, which really is
codehaus's mapper asl. To my understanding, Jackson moved from codehaus to
Github when Jackson 2 was released. The CVEs reference jackson databind, which
makes it vague whether it affects codehaus or not.
Digging a little bit deeper, there are a few good articles that describe the
CVEs better and how they relate to Jackson:
[https://adamcaudill.com/2017/10/04/exploiting-jackson-rce-cve-2017-7525/]
[https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062]
And the actual paper itself on describing the vulnerability:
[https://github.com/mbechler/marshalsec]
Reading into them, Jackson by default is not affected by the CVE. We are only
vulnerable under certain situations as described by cowtowncoder's article in
medium, which is accepting bad JSON to begin with (from what I can tell it
looks like we read in JSON when altering compaction strategy via JMX/reading in
CQL). Presumably the user wouldn't want to do it themselves so the attacker
needs to do that first.
Assuming that condition is met, ObjectMapper also needs to be able to be able
to handle polymorphic types.This can be done in 2 ways:
* ObjectMapper.enableDefaultTyping(). We don't do this in the code base.
* Explicitly defining polymorphic types using annotations JsonSubType or
JsonTypeInfo. We don't do this either.
For the record, Codehaus's ObjectMapper (Or Jackson 1's ObjectMapper) does
allow you to do this though, if we wanted to.
[https://github.com/codehaus/jackson/blob/master/src/mapper/java/org/codehaus/jackson/map/ObjectMapper.java#L848]
So I would think that it is affected (being an older version of Jackson), but
by default no and in our use case, no.
>From a user perspective some have mentioned their worries on using Jackson 1
>with Cassandra because it's no longer being updated or maintained from a
>security perspective, and in general keeping dependencies up to date is a plus
>I think.
I'm ambivalent with regards to upgrading our previous releases, I think the
pros is nothing more than not using out of date libraries and the cons is we(I)
don't know if anything will break beyond the unit tests because we don't know
what we don't know. The changes aren't very big though that said because a lot
of the code between Jackson 1 & 2 are the same.
With regards to trunk, if we can take this opportunity to, then bumping Jackson
is good practice. Those are just my thoughts :)
> Bump jackson version to >= 2.9.5
> --------------------------------
>
> Key: CASSANDRA-14427
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14427
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Lerh Chuan Low
> Assignee: Lerh Chuan Low
> Priority: Major
> Attachments: 2.1-14427.txt, 2.2-14427.txt, 3.0-14427.txt,
> 3.X-14427.txt, trunk-14427.txt
>
>
> The Jackson being used by Cassandra is really old (1.9.2, and still
> references codehaus (Jackson 1) instead of fasterxml (Jackson 2)).
> There have been a few jackson vulnerabilities recently (mostly around
> deserialization which allows arbitrary code execution)
> [https://nvd.nist.gov/vuln/detail/CVE-2017-7525]
> [https://nvd.nist.gov/vuln/detail/CVE-2017-15095]
> [https://nvd.nist.gov/vuln/detail/CVE-2018-1327]
> [https://nvd.nist.gov/vuln/detail/CVE-2018-7489]
> Given that Jackson in Cassandra is really old and seems to be used also for
> reading in values, it looks worthwhile to update Jackson to 2.9.5.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
