XStream Vulnerabilities — Detection & Mitigation

XStream Vulnerabilities — Detection & Mitigation

Looking at RCEs in the XStream Java Library and How you can prevent them

Introduction

XStream from ThoughtWorks is a simple library to serialize and deserialize objects in XML and JSON format. Compared to alternative XML serialization libraries such as JAXB (JSR-222) and Jackson, developers find XStream both lightweight and easier to integrate within their applications and services. This simplicity, however, comes at a price which is security. Until recently, XStream didn’t come with security features enabled by default. Attackers and security researchers have regularly found ways to exploit applications using XStream to perform Remote Command Execution (RCE), Denial-of-Service (DoS), and even blind Server-Side Request Forgery (SSRF). These could lead to data breaches, ransomware, and even bitcoin mining that we regularly read about.

The below table summarizes some recent CVEs reported against XStream since the pandemic.

https://medium.com/media/ec53ac02be070feacde3e3acc43e5db6/href

Detecting XStream CVEs

While the sheer number of CVEs and high CVSS base scores such as 9.8 are perturbing information for developers and application security people alike, the reality is that most of these CVEs are merely misconfiguration and highlights insecure coding practices. The number of CVEs and the base score do not mean that these vulnerabilities could be subsequently exploited by an attacker externally, a prioritization concept we call “Attacker Reachability”. While typical SCA tools such as the free dependency track (or those that come with your git) are optimized for just detecting open-source vulnerabilities, ShiftLeft Intelligent SCA is optimized for both detecting and prioritizing vulnerabilities based on Attacker Reachability.

To detect Attacker Reachable CVEs, the process employed by ShiftLeft CORE is as follows.

1. Build Software BoM (SBoM) using the CycloneDX standard
2. Overlay the vulnerability information on top of the application attack surface using our open-source Code Property Graph technology
3. Identify Attacker Reachable vulnerabilities by querying the graph database for those vulnerable packages and methods that can be reached from an attacker controlled data-flow.

By leveraging “Attacker Reachability” our platform could triage and report only those applications that are definitely exploitable due to the presence of attacker-controlled data flows. We even find applications that might include the vulnerable version of XStream but do not have a vulnerable attacker-controlled flow that performs serialization and deserialization of data.

To get started with detection, simply register for a free ShiftLeft CORE account and follow the steps to connect and scan your application via GitHub or any other CI.

Mitigation

XStream developers promptly release an update whenever a security advisory gets published. Updating the version of XStream used in your application to the latest is a good starting point, however, it is not a comprehensive solution since each new version fixes security vulnerabilities found in the previous version. In many organizations, upgrading packages frequently may not be possible due to the additional Quality Assurance and Change Management tasks involved.

An alternative to updating packages is identifying attacker-reachable flaws and adding suitable mitigation and workarounds. ShiftLeft CORE platform really excels here. For many of the XStream CVEs, a single line shown below is often enough to mitigate the reported vulnerabilities.

XStream.setupDefaultSecurity()

The above snippet enables the default security allow lists and deny lists from the open-source developers, which are not enabled by default in version 1.4.x. You could also opt for a custom allowlist based on trusted types or a combination of allow and denylists.

// Allow only the types that were reviewed and approved
XStream.allowTypes(String[]);

// If allowlist is not possible opt for deny list
XStream.denyPermission(TypePermission);
XStream.denyTypesByRegExp(String[]);
XStream.denyTypesByRegExp(Pattern[]);
XStream.denyTypesByWildcard(String[]);
XStream.denyTypeHierary(Class);

Some example denylists suggested in the advisories are listed below:

xstream.denyTypes(new String[]{ "jdk.nashorn.internal.objects.NativeString" });
xstream.denyTypes(new Class[]{ void.class, Void.class });
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[]{ ".*\\\\.ReadAllStream\\\\$FileStream" });
xstream.denyTypesByRegExp(new String[]{ ".*\\\\$LazyIterator", "javax\\\\.crypto\\\\..*", ".*\\\\.ReadAllStream\\\\$FileStream" });

Attackers have regularly found ways to exploit applications using XStream. Manage known risk from open source code with ShiftLeft’s Intelligent Software Composition Analysis (SCA) tool. Start your free 15-day trial of ShiftLeft CORE to scan your code to see if your application is at risk from XStream vulnerabilities.

---