Page History

Sometimes the OFBIz code itself is not the culprit. OFBiz relies on many Java librairies, and if one of them has a flaw we can't always wait it's fixed to warn and protect our users. This is for instance what happened with the 2015 infamous Java serialize serialization vulnerability. OFBiz was affected by 2 librairies: Apache Commons Collections and Apache Groovy . As you can see at

But with the article above the buzz began to spread and we could not wait to be able to update Groovy. So a temporary workaround was adopted as explained in

RMI and other risks

You are would though still at risk if you use RMI, JNDI, JMX or Spring and maybe other Java classes we don't use OOTB in OFBiz. We (PMC) OFBiz does not use Out Of The Box (OOTB). So the PMC decided to comment out RMI OOTB but we OOTB 

We also decided to provide a simple way to protect yourself from protect OFBiz instances from all possible Java serialize serialization vulnerabilities. While working on the serialize serialization vulnerability, I (Jacques Le Roux) stumbled upon this article "Closing the open door of java object serialization" and found decided notsoserial was a better Java agent than the one I introduced at r1717058. Because it the solution we needed. It was embedded in OFBiz and called by all running Gradle tasks until it was put in OFBiz Attic#notsoserial. So if you need a such protection you are still able to grab it from Attic and use it.

It easily protects you from all possible serialize serialization vulnerabilities as explained here! So I replaced contrast-rO0.jar by notsoserial-1.0-SNAPSHOT at r1730735 + r1730736. To be safe in case you use RMI for instance, use one of the start*-secure ant targets or use the JVM arguments those targets use.

in the notsoserial project. The idea is simple: initially you don't know what to put in your whitelist because there are some objects in OFBiz you need to put there, plus the ones you add yourself. So you initially use an empty whitelist and with the dryrun option you specify a file where the serialized objects are listed. Then you can continuously fill your whitelist to keep things secure. You can use the trace option to get a better idea of where and why an object is serialized.

ObjectInputStream

Because of

With

OWASP article (with good references at bottom)

This OWASP article is generic but simple enough to well understand the issue