[
https://issues.apache.org/jira/browse/HBASE-14799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-14799:
----------------------------------
Fix Version/s: (was: 1.0.4)
1.0.3
> Commons-collections object deserialization remote command execution
> vulnerability
> ----------------------------------------------------------------------------------
>
> Key: HBASE-14799
> URL: https://issues.apache.org/jira/browse/HBASE-14799
> Project: HBase
> Issue Type: Bug
> Components: dependencies, security
> Reporter: Andrew Purtell
> Assignee: Andrew Purtell
> Priority: Critical
> Fix For: 2.0.0, 0.94.28, 1.2.0, 1.3.0, 1.0.3, 1.1.3, 0.98.17
>
> Attachments: 14799-0.98.addendum, HBASE-14799-0.94.patch,
> HBASE-14799-0.94.patch, HBASE-14799-0.94.patch, HBASE-14799-0.94.patch,
> HBASE-14799-0.94.patch, HBASE-14799-0.98.patch, HBASE-14799-0.98.patch,
> HBASE-14799-0.98.patch, HBASE-14799.patch, HBASE-14799.patch
>
>
> Read:
> http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
> TL;DR: If you have commons-collections on your classpath and accept and
> process Java object serialization data, then you probably have an exploitable
> remote command execution vulnerability.
> 0.94 and earlier HBase releases are vulnerable because we might read in and
> rehydrate serialized Java objects out of RPC packet data in
> HbaseObjectWritable using ObjectInputStream#readObject (see
> https://hbase.apache.org/0.94/xref/org/apache/hadoop/hbase/io/HbaseObjectWritable.html#714)
> and we have commons-collections on the classpath on the server.
> 0.98 also carries some limited exposure to this problem through inclusion of
> backwards compatible deserialization code in
> HbaseObjectWritableFor96Migration. This is used by the 0.94-to-0.98 migration
> utility, and by the AccessController when reading permissions from the ACL
> table serialized in legacy format by 0.94. Unprivileged users cannot run the
> tool nor access the ACL table.
> Unprivileged users can however attack a 0.94 installation. An attacker might
> be able to use the method discussed on that blog post to capture valid HBase
> RPC payloads for 0.94 and prior versions, rewrite them to embed an exploit,
> and replay them to trigger a remote command execution with the privileges of
> the account under which the HBase RegionServer daemon is running.
> We need to make a patch release of 0.94 that changes HbaseObjectWritable to
> disallow processing of random Java object serializations. This will be a
> compatibility break that might affect old style coprocessors, which quite
> possibly may rely on this catch-all in HbaseObjectWritable for custom object
> (de)serialization. We can introduce a new configuration setting,
> "hbase.allow.legacy.object.serialization", defaulting to false.
> To be thorough, we can also use the new configuration setting
> "hbase.allow.legacy.object.serialization" (defaulting to false) in 0.98 to
> prevent the AccessController from falling back to the vulnerable legacy code.
> This turns out to not affect the ability to migrate permissions because
> TablePermission implements Writable, which is safe, not Serializable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
