Access to add and change pages is restricted. See: https://cwiki.apache.org/confluence/display/OFBIZ/Wiki+access

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

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 vulnerability. OFBiz was affected by 2 librairies: Apache Commons Collections and Apache Groovy . As you can see at Unable to render Jira issues macro, execution error. , 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 Unable to render Jira issues macro, execution error. . Since then OFBIZ-6568 has been fixed and the temporary workaround for Groovy is now unnecessary.

RMI and other risks

You are though still at risk if you use RMI, JMX or Spring and maybe other Java classes we don't use OOTB in OFBiz. We (PMC) decided to comment out RMI OOTB but we also decided to provide a simple way to protect yourself from all possible Java serialize vulnerabilities.

While working on the serialize vulnerability, I stumbled upon this article "Closing the open door of java object serialization" and found notsoserial was a better Java agent than OWASP's I introduced at r1717058. Because it easily protects you from all possible serialize vulnerabilities as explained here! So I replaced contrast-rO0.jar by notsoserial-1.0-SNAPSHOT (see Unable to render Jira issues macro, execution error. ). 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.

 

 

 

  • No labels