Managing Deserialization in XStream--the Right Way
XStream is a java library designed to make XML serialization (marshalling) easy. It handles other formats, such as JSON, as well. The mechanics of how it handles various object types frequently involve some more advanced, more risky features of Java language (for example, reflection); as such, XStream carries a bit more implicit risk in its use, and users are well-advised to be aware of its security features, as well as any needed mitigations when using older versions.
XStream recently discovered several CVEs, all of which involved taking advantage of implicit actions available to some objects at deserialization (unmarshalling) time--deserialization flaws.
The CVEs:
CVE-2021-21341 DoS
CVE-2021-21342 SSRF
CVE-2021-21343 File Deletion
CVE-2021-21344 Code Execution
CVE-2021-21345 Remote Code Execution
CVE-2021-21346 Remote Code Execution
CVE-2021-21347 Remote Code Execution
CVE-2021-21348 ReDos
CVE-2021-21349 SSRF
CVE-2021-21350 Code Execution
CVE-2021-21351 Remote Code Execution
As demonstrated by the effects described in the various CVEs above, deserialization flaws can have a range of impacts, from simple information disclosure to full-on code execution. A successful exploit frequently requires multiple elements that are beyond the attacker's control:
- acceptance of untrusted, unverified data
- lack of deserialization protections such as allow lists or deny lists
- presence of certain Java classes in the application's classpath
To protect against deserialization flaws, XStream has implemented a deny list (formerly termed "blacklist"), enabled by default, in its last several releases. These latest flaw fixes are updates to its deny lists. XStream also implemented an allow list (formerly termed "whitelist") approach.
Resolution
Content from x-stream.github.io is not included.XStream notes that users who implemented an allow list are not vulnerable to these latest flaws; only the users that rely on the provided deny list are vulnerable.
Previous experiences with allow and deny lists have led Red Hat Product Security to the conclusion that allow lists are preferred over deny lists for safeguarding serialized information:
- Less ongoing maintenance: allow lists remove the need for continued updates with every new exploitable class discovered.
- Less inherent risk: only the necessary classes are permitted to be deserialized.
If your product or application uses XStream, you should absolutely be using its available functionality to prevent XStream deserialization attacks. If you use an allow list, keep it minimal - use only the classes you need; and if you use a denylist, keep it updated to the current recommendations and mitigations.
But really, use the allow list.