Exactly a month ago, we were reporting on an issue that exposed many Java applications to security holes (remote code execution) due to how developers handled user-supplied deserialized data via the Apache Commons Collections library.
The vulnerability caused some waves in the Java community, but since the issue was not a bug in the library, but an incorrect way of handling deserialized data, there was nothing to do than to warn other developers and promote best coding practices.
According to recent research carried out by Caleb Fenton from SourceClear, 70 other libraries have the same issue when dealing with user-supplied deserialized data. See the full list at the end of this article. Some of the biggest names on this list include Apache Hadoop, Apache HBase, OpenJPA, JasperReports, and Spring XD. These libraries all invoke the Apache Commons Collections somewhere in their code and include functions that handle user-supplied deserialized data. This doesn't mean that the libraries are vulnerable, or that the applications that use them have security holes.
The issue is not bad code, but bad code writing
Problems exist only if these applications don't sanitize user-supplied data before deserializing it with one of the below-listed libraries, all of which, in turn, leave this task to the Commons Collections library. "Detecting Java deserialization vulnerabilities is tricky, to say the least. Of course, the real problem is allowing deserialization of untrusted data, but that isn’t always obvious," notes Mr. Fenton.
"This is a blind spot and it leaves us in a bad state as attackers continue to focus their efforts away from traditional targets such as end-users and individual servers and direct it upstream to developers themselves and the open source code and libraries they use." If you work with Java, you should start reviewing your code for places where you deserialize data.
