Java unserialize remote code execution hole hits Commons Collections, JBoss, WebSphere, WebLogic

Researchers from Foxglove Security have reportedly discovered a remote code execution hole in the widely used Apache Commons library, thanks to the insecure method in which Java unserializes objects, and used it to exploit JBoss, WebSphere, and WebLogic installations.

According to a blog post published over the weekend by Steve Breen of Foxglove, the vulnerability has been known for over nine months. Due to the way that Java applications bundle dependent libraries with each application, rather than using shared libraries, the vulnerability is likely to exist and be exploitable for some time.

"Every application server comes with its own bundle of libraries. Even worse, every application you deploy on the server often comes with its own set as well," Breen said. "To fix this completely, you need to find and update every single library individually."

Breen said he based his exploit on a previously released unserialize remote code execution vulnerability in Apache Commons announced in January.

Relying on how Java executes user-defined code when unserializing objects, Breen said he could craft custom payloads to give himself shell access on machines running WebLogic, WebSphere, JBoss, Jenkins, and OpenNMS, and any machine that uses Java Remote Method Invocation.

At the time he wrote his blog post, Breen said all products mentioned were vulnerable. Since that time, though, Apache and Jenkins have moved to patch their code.

Jenkins pushed out a workaround that disables the Jenkins CLI system used to attack it, with a patch expected to be released on Wednesday.

"Unfortunately, the vulnerability was not disclosed to us ahead of its publication, so we're still working on more thorough fix," the Jenkins team said.

These sentiments were echoed by Jeff Gehlbach of OpenNMS, who said on Twitter that Breen should have notified the affected projects of a 0-day vulnerability prior to publication. In response, Breen said he did not consider the vulnerability to be 0-day.

For its part, Apache Commons has added a proposed patch in its 3.2.X branch that introduces a flag to disable serialization on the vulnerable InvokerTransformer class by default.

"Using the new version of the library will mean that any attempt to de-serialize an InvokerTransformer will result in an exception," Apache Commons developer Thomas Neidhart said.