Hardened XStream with a converter to prevent exploitation

[pixeebot]

This change hardens usage of the XStream library to prevent remote code execution attacks.

XStream is a very flexible library, but it has a history of serious vulnerabilities when handling untrusted data because it was never intended for that use case. There are some fundamental issues with the design that make it difficult to make safe when using it by default.

Our change hardens new instances of XStream so that they can't deserialize types that are commonly used in exploits (and never in normal usage) and it looks like this:

+ import io.github.pixee.security.xstream.HardeningConverter;
  XStream xstream = new XStream();
+ xstream.registerConverter(new HardeningConverter());
  return (AcmeObject)xstream.fromXML(xml);

Looking at the history of exploits shows that this change will either stop most exploits or raise the bar of exploitation. If you believe there should be more types added to the denylist, please fill out a ticket with your suggestions.

❌ The following packages couldn't be installed automatically, probably because the dependency manager is unsupported. Please install them manually:

Gradle

dependencies {
  implementation("io.github.pixee:java-security-toolkit-xstream:1.0.2")
}

Maven

<dependencies>
  <dependency>
    <groupId>io.github.pixee</groupId>
    <artifactId>java-security-toolkit-xstream</artifactId>
    <version>1.0.2</version>
  </dependency>
<dependencies>

More reading

• https://x-stream.github.io/security.html
• http://diniscruz.blogspot.com/2013/12/xstream-remote-code-execution-exploit.html
• https://www.contrastsecurity.com/security-influencers/serialization-must-die-act-2-xstream
• https://x-stream.github.io/CVE-2013-7285.html

🧚🤖 Powered by Pixeebot

Feedback | Community | Docs | Codemod ID: pixee:java/harden-xstream

[pixeebot]

This library holds security APIs for hardening XStream operations.

License: MIT ✅ | Open source ✅ | No transitive dependencies ✅ | More facts

[pixeebot]

This library holds security APIs for hardening XStream operations.

License: MIT ✅ | Open source ✅ | No transitive dependencies ✅ | More facts

[pixeebot]

This library holds security APIs for hardening XStream operations.

License: MIT ✅ | Open source ✅ | No transitive dependencies ✅ | More facts

[pixeebot]

This library holds security APIs for hardening XStream operations.

License: MIT ✅ | Open source ✅ | No transitive dependencies ✅ | More facts

[pixeebot]

This library holds security APIs for hardening XStream operations.

License: MIT ✅ | Open source ✅ | No transitive dependencies ✅ | More facts

[pixeebot]

This library holds security APIs for hardening XStream operations.

License: MIT ✅ | Open source ✅ | No transitive dependencies ✅ | More facts

[pixeebot]

This library holds security APIs for hardening XStream operations.

License: MIT ✅ | Open source ✅ | No transitive dependencies ✅ | More facts

[pixeebot]

This library holds security APIs for hardening XStream operations.

License: MIT ✅ | Open source ✅ | No transitive dependencies ✅ | More facts

[pixeebot]

This library holds security APIs for hardening XStream operations.

License: MIT ✅ | Open source ✅ | No transitive dependencies ✅ | More facts

[pixeebot]

This library holds security APIs for hardening XStream operations.

License: MIT ✅ | Open source ✅ | No transitive dependencies ✅ | More facts

[pixeebot]

I'm confident in this change, but I'm not a maintainer of this project. Do you see any reason not to merge it?

If this change was not helpful, or you have suggestions for improvements, please let me know!

[pixeebot]

Merging this change just means the code won't be able to deserialize types like java.lang.Runtime or java.lang.ProcessBuilder -- which is always a good thing. Not having a control like this is how this exploit against Jenkins happen.

If there are other concerns about this change, I'd love to hear about them!