Other languages have considered deserializing data a security issue, especially when done across a trust boundary, such as across a network. However Java has a long history of deserializing data sent from across the network, which started with the predecessor to EJB, CORBA.
Unfortunately lots of deserialization of untrusted data still goes on in modern Java applications. The reason its topical now, is that recent gadget chains tools created by Chris Frohoff and Gabriel Lawrence have made exploiting this type of weakness accessible by your average script kiddie.
Luckily JBoss, took steps years ago to reduce their exposure to deserialization by switching from a JMX MBean managment and configuration model, to a more secure management interface in JBoss AS 7. The new management interfaces only bind on the loopback network interface by default, and are secured with authentication out of the box.
That’s not to say that deserialization does not occur at all, and their taking steps to reduce their exposure further. Some of the tools you can use to find, and plug holes in Java applications include network packet sniffing with MITMProxy, and I plan to experiment with Direct Defence’s SuperSerial extender for Burp suite.
With the advent JDK9 the Java community is hoping to see some performance improvements in the Java Security Manager, such as JEP 232, as well as the introduction of ValueTypes. I also really like notsoserial put together by Kantega to blacklist risky classes from deserialization with byte code instrumentation, as a direct response to these kind of vulnerablities. Although I’d still consider it a band-aid approach.
The Java community have to be aware that the recently discovery of gadget chains utilizing the Apache commons-collections weakness are just the tip of the iceberg. The real solution is avoiding Java deserializaiton altogether. That means avoiding JMX Management over RMI, JMS ObjectMessage and others. Where we can’t avoid it, at least making sure those endpoints are protected by authentication. Thanks to Will Sargent, of Terse Systems for this inspiring blog post on the same topic.
Secure Software Engineering 