You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Andrew Purtell (JIRA)" <ji...@apache.org> on 2019/07/25 00:10:00 UTC
[jira] [Comment Edited] (HBASE-22728) Upgrade jackson dependencies
in branch-1
[ 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)