Andrew Purtell created HBASE-14799:
--------------------------------------
Summary: 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
Reporter: Andrew Purtell
Priority: Critical
Fix For: 0.94.28, 0.98.17
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 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 would need to be changed to 'true' to re-enable support of auto-migration
of ACL data whenever migrating from 0.94.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
