Researchers from Foxglove Security have confirmed deserialization vulnerabilities in third-party Java libraries that could be used to remotely exploit JBoss, WebSphere, Jenkins, WebLogic, and OpenNMS installations, among others. While the issue could potentially exist in many applications, the vulnerability is in how developers deal with user-supplied serialized data and not the libraries themselves.
The issue exists in cases where the application accepts serialized Java objects as input. Unserialize vulnerabilities arise when developers accept serialized data -- application data that's been converted to another format -- as user input, then attempt to read back data.
In the case of Apache Commons Collections, the attacker would exploit the flow by providing a serialized class from commons-collections as input. Commons-collections by design executes the class's code during its deserialization process.
It may be obvious, but it doesn't hurt to reiterate the point: Do not serialize objects with executable code from the Internet.
Foxglove Security's Steve Breen noted in a detailed blog post that commercial applications weren't the only ones affected. Custom Java applications using vulnerable versions of third-party libraries, such as Apache Commons Collections, Groovy, or Spring, may also be vulnerable. The Foxglove team posted a proof of concept on GitHub based on a previously released unserialize remote code execution vulnerability in Apache Commons from January.
Foxglove demonstrated the attack against WebSphere via a SOAP request to the AdminService and a similar attack against JBoss via a request to the JMXInvoker service. Any javax.management port that uses remote object serialization and has vulnerable libraries is potentially vulnerable. Any server running RMI is potentially vulnerable, but if RMI ports are open to the Internet, the server has bigger security problems to worry about.
Before anyone panics about the prospect of yet another remote code execution exploit hitting Java applications, it's worth noting that while the problem is serious and potentially widespread, it is not nearly as critical as the blog post made it sound. Breen described the issue as "the most underrated, underhyped vulnerability of 2015." But the fact remains that this is not a problem with Java or even Apache Commons Collections, but rather, with the use of libraries.
Developers should reject any input of serialized objects in their applications. If the application must accept serialized objects, then user input should be sanitized first.
"If the application doesn't whitelist the classes it deserializes from an untrusted user, you deserve everything you get," a user named artbristol wrote on Slashdot.
Since Jenkins uses object serialization though the Jenkins CLI interface, it's vulnerable to anyone who can reach that port. CloudBees, one of the primary sponsors of Jenkins, released a workaround in the form of a Groovy script to disable or remove the Jenkins CLI subsystem inside of the running server.
The fact that the applications called out in the blog post were not sanitizing the input is a little worrying, but the fixes are already in place or on the way. WebSphere Application Server appear to have fixed the issue back in April. The exploit in Groovy has been fixed in 2.4.4 earlier this year, as part of its release from the Apache Foundation. Users are advised to upgrade to the current release of Groovy from Apache to avoid this specific issue. Jenkins promised a fix on or before Wednesday.
The team for Apache Commons added a proposed patch in its 3.2.X branch that introduces a flag to disable serialization on the vulnerable InvokerTransformer class by default. The new version of the library will throw an exception if anyone attempts to deserialize an InvokerTransformer.
OpenNMS users can disable the attack vector by simply configuring the server's firewall to disable remote access to port 1099, the team said in a blog post. The ideal setup is to run something like iptables on the OpenNMS server and limit remote access to a minimal set of ports, such as port 22 for ssh and port 162 for SNMP trap reception. The application needs access to other ports from localhost, but that limits exposure to only people who already have shell access to the server.
Jeff Gehlbach, a consultant at OpenNMS, pointed out on Twitter that OpenNMS had a dedicated email address for reporting security issues, and Foxglove researchers chose not to use it to notify the team beforehand. In fact, none of the affected applications called out in the blog post were told beforehand of the zero-day flaw.
Breen defended the decision, noting it was not reasonable to expect the team to reach out to everyone using the library incorrectly. Another member of the Foxglove Security team also noted that the vulnerability was not considered a zero-day. That seems like a spurious argument, since Breen specifically noted the exploits leveraged vulnerabilities for products that have not yet been patched.
"Our customers with bug fix support SLAs will consider it zero-day, rightly or not," Gehlbach said. Even though blocking access to the port will prevent any problems on OpenNMS, the team is looking into how to better protect against this issue from a code change standpoint.
Developers should make sure to update the affected libraries when the fixed versions are available. And they should take steps to properly handle serialized objects in their Java applications where they are accepted.