Bug 1908837 (CVE-2020-26259) - CVE-2020-26259 XStream: arbitrary file deletion on the local host when unmarshalling
Summary: CVE-2020-26259 XStream: arbitrary file deletion on the local host when unmars...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2020-26259
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1908838
Blocks: 1908839
TreeView+ depends on / blocked
 
Reported: 2020-12-17 17:40 UTC by Guilherme de Almeida Suckevicz
Modified: 2021-12-14 21:33 UTC (History)
55 users (show)

See Also:
Fixed In Version: xstream-1.4.15
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-26 23:32:14 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2021:2475 0 None None None 2021-06-17 13:15:07 UTC
Red Hat Product Errata RHSA-2021:2476 0 None None None 2021-06-17 13:19:33 UTC
Red Hat Product Errata RHSA-2021:4767 0 None None None 2021-11-23 10:34:41 UTC
Red Hat Product Errata RHSA-2021:5134 0 None None None 2021-12-14 21:33:26 UTC

Description Guilherme de Almeida Suckevicz 2020-12-17 17:40:48 UTC
XStream is a Java library to serialize objects to XML and back again. In XStream before version 1.4.15, is vulnerable to an Arbitrary File Deletion on the local host when unmarshalling. 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. If you rely on XStream's default blacklist of the Security Framework, you will have to use at least version 1.4.15. The reported vulnerability does not exist running Java 15 or higher. No user is affected, who followed the recommendation to setup XStream's Security Framework with a whitelist! Anyone relying on XStream's default blacklist can immediately switch to a whilelist for the allowed types to avoid the vulnerability. Users of XStream 1.4.14 or below who still want to use XStream default blacklist can use a workaround described in more detailed in the referenced advisories.

References:
https://github.com/x-stream/xstream/security/advisories/GHSA-jfvx-7wrx-43fh
https://x-stream.github.io/CVE-2020-26259.html

Comment 1 Guilherme de Almeida Suckevicz 2020-12-17 17:41:12 UTC
Created xstream tracking bugs for this issue:

Affects: fedora-all [bug 1908838]

Comment 3 Paramvir jindal 2020-12-24 12:43:27 UTC
This vulnerability is out of security support scope for the following products:

 * Red Hat Data Grid 7
 * Red Hat JBoss BRMS 6
 * Red Hat JBoss BPMS 6
 * Red Hat JBoss Data Virtualization 6
 * Red Hat JBoss Fuse 6
 * Red Hat JBoss Fuse Service Works 6
 * Red Hat JBoss SOA Platform 5

Please refer to https://access.redhat.com/support/policy/updates/jboss_notes for more details.

Comment 6 Paramvir jindal 2020-12-24 12:47:25 UTC
Mitigation:

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

Comment 8 Przemyslaw Roguski 2021-01-04 15:46:33 UTC
Upstream commit:
https://github.com/x-stream/xstream/commit/0bcbf50126a62dfcd65f93a0da0c6d1ae92aa738

Comment 9 Przemyslaw Roguski 2021-01-04 15:46:39 UTC
Statement:

OpenShift Container Platform (OCP) delivers jenkins package with bundled XStream library. Due to JEP-200 Jenkins project [1] and advisory SECURITY-383 [2], OCP jenkins package is not affected by this flaw.

[1] https://github.com/jenkinsci/jep/blob/master/jep/200/README.adoc
[2] https://www.jenkins.io/security/advisory/2017-02-01/  (see SECURITY-383 / CVE-2017-2608)

Comment 12 errata-xmlrpc 2021-05-26 21:49:56 UTC
This issue has been addressed in the following products:

  Red Hat Data Grid 8.2.0

Via RHSA-2021:2139 https://access.redhat.com/errata/RHSA-2021:2139

Comment 13 Product Security DevOps Team 2021-05-26 23:32:14 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2020-26259

Comment 14 errata-xmlrpc 2021-06-17 13:14:58 UTC
This issue has been addressed in the following products:

  RHPAM 7.11.0

Via RHSA-2021:2475 https://access.redhat.com/errata/RHSA-2021:2475

Comment 15 errata-xmlrpc 2021-06-17 13:19:24 UTC
This issue has been addressed in the following products:

  RHDM 7.11.0

Via RHSA-2021:2476 https://access.redhat.com/errata/RHSA-2021:2476

Comment 17 errata-xmlrpc 2021-11-23 10:34:38 UTC
This issue has been addressed in the following products:

  Red Hat Integration

Via RHSA-2021:4767 https://access.redhat.com/errata/RHSA-2021:4767

Comment 18 errata-xmlrpc 2021-12-14 21:33:23 UTC
This issue has been addressed in the following products:

  Red Hat Fuse 7.10

Via RHSA-2021:5134 https://access.redhat.com/errata/RHSA-2021:5134


Note You need to log in before you can comment on or make changes to this bug.