A vulnerability originating from a commonly used Java library is affecting a broad range of commercial and custom software across global networks, according to Foxglove Security. As such, it will be difficult to isolate and neutralize.
Technically, the issue is considered an "unserialized remote code execution hole.”
As Foxglove explains: “Most programming languages provide built-in ways for users to output application data to disk or stream it over the network. The process of converting application data to another format (usually binary) suitable for transportation is called serialization. The process of reading data back in after it has been serialized is called unserialization.”
The vulnerability, first discovered more than nine months ago, is a class rather than a specific issue.
“It's important to remember that deserialization vulnerabilities are a class of vulnerability, and not a particular vulnerability, just as a ‘stack-based buffer overflow’ is a class of vulnerabilities,” Tod Beardsley, principal security research manager at Rapid7 told us. “Every language that supports serialization is susceptible to deserialization vulnerabilities when the functions are used in an unsafe way; the original presentation by Frohoff and Lawrence detail the condition in Python, PHP, and Ruby as well.”
The flaw is located in Apache Commons, a library that contains a widely used set of Java components maintained by the Apache Software Foundation. There are multiple exploits in the wild for this, using major networking software packages including WebLogic, WebSphere, JBoss, Jenkins, and OpenNMS. As these are application servers that are used to deploy distributed enterprise applications, among other uses, this puts many Java-based applications at risk.
To date there is no catchy name for this vulnerability (like Poodle, or Heartbleed)—which, NTT Com Security pointed out, could be part of the problem. There seems to be a continued lack of awareness of the seriousness of the impact, which NTT Com describes as worse than Heartbleed and harder to fix.
"It would be difficult to overstate the magnitude of this problem. The core issue arises from architectural decisions that are very common in the Java world. This leaves many web servers and custom Java applications vulnerable to attack," said Christopher Camejo, director of threat and vulnerability analysis at NTT Com Security. "And because the code is in a library, there is no efficient, centralized way to fix it, such as a patch or update. The community at large is still trying to figure out the best way to address this on a wide scale."
The process of patching is underway, but this is unlikely the end of the story. “Java web servers are still very common, and as both offensive and defensive security researchers learn more about the particular implementations of these rather large and complex applications, we all will undoubtedly uncover more examples of deserialization bugs,” Beardsley noted.
Apache and Oracle, as a core language maintainer for the affected code, are in a great position to warn their developer communities against using these functions in an unsafe way.
“In general, more should be done in educating developers, especially when we can see that major projects with world-class Java developers accidentally expose critical vulnerabilities using common Java functions,” Beardsley said.