CVE-2021-39144 XStream Deserialization Remote Code Execution

Solution Verified - Updated -

Environment

Refer to the CVE page

Issue

Xstream is a java component that simplifies serialization and deserialization of objects - converting them into XML and back again, for use in transport across the network. Xstream uses some advanced Java features, notably Reflection, which allows bypassing some of the language's controls and restrictions, and thus brings a heightened risk.

Resolution

Many Red Hat products do not use XStream directly in their code but there are many components that have XStream as a dependency, and have been assessed as Low security impact.

Also various Red Hat products have already resolved the issue with previous XStream CVEs, via implementing an allowlist approach to their usage.

Root Cause

Largest among those risks are deserialization flaws, which rely on special configured object bundles (usually called "gadgets") that will trigger certain behaviors when an object is created from XML.

The common guidance for managing Java deserialization flaws is to restrict the classes that can be serialized and deserialized, usually taking the form of a deny-list (formerly "blacklist") or an allow-list (formerly "whitelist"). Overwhelmingly, the allowlist is much more secure and much less long-term overhead, in exchange for some configuration needed for the server. Despite this, several component communities have chosen to maintain a denylist by default, permitting users to override with allowlists as they see fit; invariably, this approach of denylist-by-default has proven problematic because of continual CVE updates needed and the associated effort required. For more information, see the Red Hat Article about serialization issues

CVE-2021-39144 is yet another of these flaws. The fix for this was to finally remove the default blacklist approach: "XStream 1.4.18 uses no longer a blacklist by default, since it cannot be secured for general purpose."
Source: xstream security advisory*

Thus, products that adopt the patch for this flaw simply no longer have a default denylist to use out of the box, and will have to implement their own allowlist. The products that have implemented an allowlist already are not vulnerable to this flaw.

Diagnostic Steps

References:

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments