[
https://issues.apache.org/jira/browse/HBASE-22728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16892292#comment-16892292
]
Andrew Purtell edited comment on HBASE-22728 at 7/25/19 12:09 AM:
------------------------------------------------------------------
Although this is the Codehaus Jackson and not the Fasterxml Jackson and
specifically the jackson-databind artifact is not pulled in, the CVE does
implicate org.codehaus.jackson:jackson-mapper-asl 1.9.13. (See
https://www.cvedetails.com/cve/CVE-2017-7525/).
We are not going to see a new version of Codehaus Jackson and we are not going
to be able to upgrade to Fasterxml Jackson without maybe breaking downstreamers
by removing org.codehaus.jackson artifacts from the classpath (pulled in now by
hbase-client, hbase-server, and others).
I think we have to do a code analysis to determine if we call
ObjectMapper#readValue directly or indirectly using untrusted user input to
determine if RCE in an HBase process is possible. hbase-rest has the most
exposure I'd imagine. An upgrade of Jersey and Jackson dependencies in
hbase-rest alone would be a contained change. To do this we'd essentially
backport the branch-2 version of hbase-rest.
Otherwise I wonder if we can fix our POMs to not expose a dependency on
jackson-mapper-asl so we wouldn't pull a vulnerable version into someone else's
project unnecessarily.
[~Apache9] [~busbey] [~elserj] [~stack] [~toffer]
was (Author: apurtell):
Although this is the Codehaus Jackson and not the Fasterxml Jackson and
specifically the jackson-databind artifact is not pulled in, the CVE does
implicate org.codehaus.jackson:jackson-mapper-asl 1.9.13. (See
https://www.cvedetails.com/cve/CVE-2017-7525/).
We are not going to see a new version of Codehaus Jackson and we are not going
to be able to upgrade to Fasterxml Jackson without maybe breaking downstreamers
by removing org.codehaus.jackson artifacts from the classpath (pulled in now by
hbase-client, hbase-server, and others).
I think we have to do a code analysis to determine if we call
ObjectMapper#readValue directly or indirectly using untrusted user input to
determine if RCE in an HBase process is possible. hbase-rest has the most
exposure I'd imagine. An upgrade of Jersey and Jackson dependencies in
hbase-rest alone would be a contained change. To do this we'd essentially
backport the branch-2 version of hbase-rest.
Otherwise I wonder if we can fix our POMs to not expose a dependency on
jackson-mapper-asl so we wouldn't pull a vulnerable version into someone else's
project unnecessarily.
> Upgrade jackson dependencies in branch-1
> ----------------------------------------
>
> Key: HBASE-22728
> URL: https://issues.apache.org/jira/browse/HBASE-22728
> Project: HBase
> Issue Type: Sub-task
> Affects Versions: 1.4.10, 1.3.5
> Reporter: Andrew Purtell
> Priority: Major
> Fix For: 1.5.0, 1.3.6, 1.4.11
>
>
> Avoid Jackson versions and dependencies with known CVEs
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
