hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-14799) Commons-collections object deserialization remote command execution vulnerability
Date Thu, 12 Nov 2015 02:53:10 GMT

     [ https://issues.apache.org/jira/browse/HBASE-14799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andrew Purtell updated HBASE-14799:
-----------------------------------
    Description: 
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. 

  was:
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 would need to be changed to 'true' to re-enable support of auto-migration
of ACL data whenever migrating from 0.94.


> 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
>
>         Attachments: HBASE-14799-0.94.patch, HBASE-14799-0.98.patch, HBASE-14799-0.98.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)

Mime
View raw message