Java libraries are full of deserialization security bugs

Boffins at universities in France, Germany, Luxembourg, and Sweden took a deep dive into known Java deserialization vulnerabilities, and have now resurfaced with their findings. In short, they’ve drawn attention to the ways in which libraries can accidentally introduce serious security flaws.

Serialization is used to convert a data object in memory into a series of bytes for storage or transmission. Deserialization reverses that process by turning a data stream back into an object in memory.

In Java, this is implemented using the interface. But deserialization isn’t necessarily safe because reconstructing the object from its byte stream doesn’t involve the constructor – the blueprint code that initially builds the object to have whatever functions and methods it should have. If the constructor had any validation checks, those don’t get run. Thus it’s possible for deserialization to create objects that are invalid or have altered data.

Java deserialization bugs can be fairly serious.

For example, Log4Shell, the remote code execution flaw affecting the Apache Log4j logging library was made possible by Java deserialization. In November 2016, a ransomware attack compromised more than two thousand computers run by the San Francisco Municipal Transportation Agency (SFMTA) via an Apache Commons Collections Deserialization Vulnerability.

Also, the entry point for the 2017 Equifax hack that resulted in the theft of personal data from 147.7 million Americans came from a Java deserialization flaw in Apache Struts. And last July, there was an Atlassian Jira vulnerability in which an attacker capable of connecting to an Ehcache RMI network service “could execute arbitrary code of their choice in Jira through deserialization due to a missing authentication vulnerability.”

In a paper titled, “An In-depth Study of Java Deserialization Remote-Code Execution Exploits and Vulnerabilities,” computer scientists Imen Sayar (University of Toulouse), Alexandre Bartel (Umeå University), Eric Bodden (Paderborn University), and Yves Le Traon (University of Luxembourg) describe how they examined software libraries targeted by 19 publicly known Java deserialization RCE exploits to understand how gadgets – exploitable code constructs – get introduced into Java libraries and how attempts to get rid of gadgets sometimes fail.

While serialization and deserialization are useful, the authors observe, this process introduces risk if the deserialized data comes from an untrusted source. “Indeed, an attacker could craft a byte stream that, when deserialized on the remote host, could control the execution flow of the Java code by chaining sequences of Java code called gadgets,” they explain.

The term gadget has a few specific meanings in the world of vulnerability exploitation. For their paper, the authors use the word to refer to a Java method accessible to the attacker. The key thing here is that a library may contain gadgets that may be chainable, so they can operate in a sequence.

Taking advantage of a deserialization vulnerability can involve a complicated attack chain or it may be as simple as making a GET request over a network.

Our main conclusion is that the modification of one innocent-looking detail in a class – such as making it public – can already introduce a gadget

The researchers looked at 19 exploits for vulnerabilities in 14 libraries (some with multiple versions): beanshell, clojure, commons-beanutils, commons-collections, groovy, rome, js-rhino, spring-beans, spring-core, spring-aop, click-nodeps, javax.servlet, vaadin-server, and vaadin-shared.

“When analyzing the 19 RCE exploits, we have identified several ways to introduce a gadget in a library: adding classes, methods, and interfaces, or changing the signature of methods,” the paper reads. “Our main conclusion is that the modification of one innocent-looking detail in a class – such as making it public – can already introduce a gadget.”

Given that gadgets are necessary to create a deserialization exploit, code modification that inserts new gadgets is clearly not ideal.

Of the libraries and their variants tested, 14 have been patched to remove potential gadgets. This can be done in various ways, such as removing from the list of interfaces in a vulnerable class, removing the vulnerable class in its entirety, or introducing a safety check, among other techniques.

Six of the libraries evaluated (commons-beanutils1.9.4, rome1.0, spring-beans-3.0.0.RELEASE, click-nodeps-2.3.0-RC1, javax-servlet-api-4.0.1, and vaadin-shared-7.4.0.beta1) are listed as not patched. So if your applications include any of them, you may want to consider how to address that. Waiting for a fix, however, may not be the best option.

“When studying patches of such libraries, we observed that the time used to remove gadgets varies between several months and almost 12 years, with an average of almost six years,” the researchers conclude. “It thus appears that deserialization vulnerabilities do not yet get the attention of practitioners that they should actually deserve.” ®

Source link

Back to top button