Thousands of Java applications vulnerable to nine-month-old remote code execution exploit

Thousands of Java applications vulnerable to nine-month-old remote code execution exploit 

 
A popular Java library has a serious vulnerability, discovered over nine months ago, that continues to put thousands of Java applications and servers at risk of remote code execution attacks.
The flaw is located in Apache Commons, a library that contains a widely used set of Java components maintained by the Apache Software Foundation. The library is used by default in multiple Java application servers and other products including Oracle WebLogic, IBM WebSphere, JBoss, Jenkins and OpenNMS.
The flaw is specifically in the Collections component of Apache Commons and stems from unsafe deserialization of Java objects. In programming languages, serialization is the process of converting data to a binary format for storing it in a file or memory, or for sending it over the network. Deserialization is the reverse of that process.
The vulnerability was first reported at a security conference in January by researchers Chris Frohoff and Gabriel Lawrence, but it didn’t receive a lot of attention, possibly because many people believe the responsibility for preventing deserialization attacks lies with Java application developers, not the library’s creators.
“I don’t feel the library is to blame, though improvements certainly could be made,” said Carsten Eiram, the chief research officer at vulnerability intelligence firm Risk Based Security, via email. “End of day, untrusted input should never be blindly deserialized. Developers should understand how a library works and validate input passed to it instead of trusting or hoping the library does it safely for them.”
The vulnerability received a new wave of exposure Friday after researchers from a company called FoxGlove Security released proof-of-concept exploits based on it for WebLogic, WebSphere, JBoss, Jenkins and OpenNMS.
In response, Oracle issued a security alert Tuesday containing temporary mitigation instructions for the WebLogic Server while the company is working on a permanent patch. The Apache Commons Collections developers have also started working on a fix.
Apache Commons Collections contains an InvokerTransformer class that performs reflection, or dynamic method invocation, and which can be included in a serialized object. This can allow an attacker to craft a user-supplied object with malicious content that would get executed when the object is deserialized by a Java application using the Apache Commons library.

The InvokerTransformer class itself is not bad and neither is serialization, but it’s when they’re combined that the security issue appears, said Joshua Corman, the CTO of Sonatype, a software supply chain automation company that helps developers track and manage the components they use in their applications.
Corman and Bruce Mayhew, a security researcher with the company, believe that this issue is not limited to Apache Commons Collections and that other Java components might have the same problem.
“I guarantee you that there are now a bunch of people who are combing through all the most common components looking for serializable classes that allow for some sort of command execution,” Mayhew said. “These are probably both good and bad guys.”
Even in the context of Apache Commons Collections, InvokerTransformer might not be the only vulnerable class, according to discussions on the component’s bug tracker. There are three others that have been singled out as candidates for having the same problem.
The FoxGlove Security researchers searched the public software projects hosted on GitHub for use of “commons-collection” and found 1,300 results. However, there are likely thousands more custom-built Java applications in enterprise environments that use the library.
Even though there’s a strong possibility that this problem goes beyond this particular component, until a patch is released, developers should consider whether they can remove commons-collections from the classpath or remove the InvokerTransformer class from the common-collections jar file. Such changes should be considered carefully, as they could break applications.