[<prev] [next>] [day] [month] [year] [list]
Date: Mon, 22 May 2017 13:47:43 +0200
From: Moritz Bechler <mbechler@...terphace.org>
To: oss-security@...ts.openwall.com
Subject: Code Execution through a variety Java (Un-)Marshallers
Hi,
(As per list policy I tried to include the most relevant information,
but I don't think including the full details makes any sense - hope that
is okay.)
Full paper as well as payload generation tools are available at
<https://www.github.com/mbechler/marshalsec/>
Over the past two years we have seen a great number of vulnerabilities
resulting from careless use of Java serialization.
This research shows that issues like that are in no way limited to
mechanisms as expressive or "powerful" as Java serialization but can be
generalized to a wide range of other ones.
Any unmarshaller that performs object binding, implicitly (e.g. magic
methods on collection insertion) or explicitly (e.g. property setters)
executes behaviors attached to the object's type (read: calls
methods/executes codes).
To do their work these mechanisms need to assume some kind of contract
on these behaviors - simply put, they should not have any side effects.
In practice however these conventions are broken quite often, either
deliberately or unconsciously, and can lead to the execution of code
with unwanted side-effects, in the worst case trigger command or remote
code execution.
Many mechanisms embed type information in their outputs. In some form
this is always required to properly restore polymorphic types (and pre
Java 1.5 this was even required for regular collections as well).
Insufficiently restricting the types that can be used there however
means that an attacker can trigger these behaviors on more or less
arbitrary types on the classpath (which in a normal Java projects is a
humongous amount of code no-one fully understands - standard library
alone...).
That usually is enough to achieve RCE, in some cases using some third
party library code, in many cases even universally through code in the
Java standard library.
Even the most restrictive implicit (technical) type restrictions (e.g.
constructor requirements) that can be applied by these mechanisms are
insufficient to prevent these issues. With Java's java.io.Serializable
we have already seen a model fail where the types themselves declare
their intent to be used in such a situation (for various reasons),
although not having such a restriction seems even worse.
The only option left is explicit restriction to types known to fulfill
the contract by the user, be that in the form of registration (e.g. JAXB
or a variety of mechanisms requiring schema definitions or compilation),
an explicit whitelist or strict runtime type checking from a root type.
Hybrid type checking and registration like found in GSON or Jackson with
JsonTypeInfo.Id.Name so far seem to offer the best balance between
convenience and security.
While in the best case scenario one would restrict to data objects not
containing any logic at all -- for practical purposes restricting to the
types that are actually used seems good enough, usually it's the ton of
code that you don't even care about that will get you pwned.
(Open Source) marshaller libraries (some pretty rare, but for the sake
of completeness) that allow(ed) for unmarshalling into arbitrary types,
their their known worst case impacts and possible mitigations, are
-------------------------------
Apache BlazeDS AMF Marshalling
- JDK only escalation to Java serialization
- third party library RCEs (spring, c3p0)
Mitigations: Configure a DeserializationValidator for type whitelisting.
Upgrade to 4.7.3 which enables it by default (CVE-2017-5641).
-------------------------------
Hessian/Burlap:
- third party library RCEs (spring, rome, xbean-naming, resin)
Mitigation: Upgrade to 4.0.51 and enable type whitelisting through
ClassFactory.
-------------------------------
Castor:
-> POM dependency library RCE (spring)
Mitigation: N/A
-------------------------------
Jackson:
- >=2.7.0: not totally reliable JDK only RCE
- possibly JDK only escalation to Java serialization
- third party library RCEs (spring, c3p0)
Jackson takes a somewhat special position here, in that by default it is
unaffected but only becomes exploitable when class based polymorphism is
enabled
(https://github.com/FasterXML/jackson-docs/wiki/JacksonPolymorphicDeserialization)
and there are unbounded or insufficiently bounded properties.
Mitigation: Use explicit polymorphism with JsonTypeInfo.Id.Name
-------------------------------
Java serialization:
- one new library gadget
-------------------------------
Java XMLDecoder:
- well, we know about that one...
-------------------------------
json-io
-> JDK only RCE
Mitigation: N/A
-------------------------------
jYAML
-> JDK only RCE
Mitigation: N/A
-------------------------------
Kryo:
- using default instantiation: third party RCEs (commons-beanutils, spring)
- using StdInstantiatorStrategy: JDK only RCE
Mitigation: Enforce type registration
-------------------------------
Red5 AMF Marshalling:
-> JDK only RCE
Mitigation: Upgrade to 1.0.8 which enables type blacklisting :( of the
known bad ones
-------------------------------
SnakeYAML
-> JDK only RCE
Mitigation: Use SafeConstructor or a custom implementation for type
whitelisting.
-------------------------------
XStream
-> JDK only RCE
Mitigation: Use XStream's TypePermission for type whitelisting.
-------------------------------
YAMLBeans:
- third party library RCE (c3p0)
Mitigation: N/A
-------------------------------
Vulnerabilities where one of these was exploitable under some
circumstances identified as a part of this research and have been fixed
include:
- JBoss Resteasy - SnakeYAML (CVE-2016-9606)
- Apache Camel - SnakeYAML/Jackson/... (CVE-2017-3159,CVE-2016-8749)
- Apache Brooklyn - SnakeYAML (CVE-2016-8744)
- Jenkins - XStream (CVE-2017-2608)
- Red5 Media Server/Apache OpenMeetings (CVE-2017-5878)
- Magnolia CMS - json-io (CVE N/A, tracking MGNLCACHE-165)
- OpenNMS - Castor (CVE N/A, tracking NMS-9099/9100)
- Atlassian Bamboo - XStream (CVE 2016-5229)
- Adobe Coldfusion - BlazeDS (CVE 2017-3066)
Other affected instances, which have been reported but the author hasn't
recently received feedback on their current state include: Caucho Resin
(Hessian), Netflix Eureka (XStream), Amazon's AWS Simple Workflow
Library (Jackson).
regards
Moritz
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
