Page History

...

Info
title Pre Gradle version
This page documents the usage with Gradle, the pre-Gradle documentation is here: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=65865828

 

Table of Contents

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 serialization vulnerability. OFBiz was affected by 2 librairies: Apache Commons Collections and Apache Groovy . As you can see at

Jira
server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key OFBIZ-6726

, we waited the Commons Collections update to fix the issue, because it was not much disclosed then.

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

Jira
server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key OFBIZ-6568

. Since then OFBIZ-6568 has been fixed and the temporary workaround for Groovy is now unnecessary.

RMI and other risks

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

Jira
server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key OFBIZ-6942

. But we could do nothing to prevent the other possiblities (not concerned OOTB). Note also that in the last release of the R12.04 branch (12.04.06) RMI is not deactivated so you should use the recommended remediation below.

We also decided to provide a simple way to protect OFBiz instances from all possible Java serialization vulnerabilities. While working on the serialization vulnerability, I stumbled upon this article "Closing the open door of java object serialization" and decided notsoserial was the solution we needed. It 's now 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 serialization vulnerabilities as explained 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

Jira
server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key OFBIZ-10837

, we needed to fix another issue related to ObjectInputStream class. If you encounter a related issue (object not in the allow list), you must provide a complete list of objects to pass to ObjectInputStream through ListOfSafeObjectsForInputStream property in SafeObjectInputStream.properties file. As an example, the a complete list of objects  used by OFBiz OOTB is by default there. You will need to add your objects/classes to this list.

With

Jira
server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key OFBIZ-12167

we have introduced a way to also put objects in a deny list and improved it with

Jira
server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key OFBIZ-12216

,

Jira
server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key OFBIZ-12212

and

Jira
server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key OFBIZ-12221

OWASP article (with good references at bottom)

...