[CVE-2019-0189] Apache OFBiz remote code execution and arbitrary file delete via Java deserialization
Severity: Important Vendor: The Apache Software Foundation Versions Affected: OFBiz 16.11.01 to 16.11.05 Description: The java.io.ObjectInputStream is known to cause Java serialisation issues. This issue here is exposed by the "webtools/control/httpService" URL, and uses Java deserialization to perform code execution. In the HttpEngine, the value of the request parameter "serviceContext" is passed to the "deserialize" method of "XmlSerializer". Ofbiz is affected via two different dependencies: "commons-beanutils" and an out-dated version of "commons-fileupload" Mitigation: Upgrade to 16.11.06 or manually apply the commits from OFBIZ-10770 AND OFBIZ-10837 on branch 16 Credit: Man Yue Mo of the Semmle Security Research Team ricterzheng(郑杜涛) References: http://ofbiz.apache.org/download.html#vulnerabilities
[CVE-2018-17200] Apache OFBiz unauthenticated remote code execution vulnerability in HttpEngine
Severity: Important Vendor: The Apache Software Foundation Versions Affected: OFBiz 16.11.01 to 16.11.05 Description: The OFBiz HTTP engine (org.apache.ofbiz.service.engine.HttpEngine.java) handles requests for HTTP services via the /webtools/control/httpService endpoint. This service takes the `serviceContent` parameter in the request and deserializes it using XStream. This `XStream` instance is slightly guarded by disabling the creation of `ProcessBuilder`. However, this can be easily bypassed (and in multiple ways). Mitigation: Upgrade to 16.11.06 or manually apply the following commits on branch 16 r1850017+1850019 Credit: Man Yue Mo of the Semmle Security Research Team 张剑 References: http://ofbiz.apache.org/download.html#vulnerabilities
[CVE-2019-10074] Apache OFBiz RCE (template injection)
Severity: Important Vendor: The Apache Software Foundation Versions Affected: OFBiz 16.11.01 to 16.11.05 An RCE is possible by entering Freemarker markup in an OFBiz Form Widget textarea field when encoding has been disabled on such a field. This was the case for the Customer Request "story" input in the Order Manager application. Encoding should not be disabled without good reason and never within a field that accepts user input. Mitigation: Upgrade to 16.11.06 or manually apply the following commit on branch 16.11: r1858533 Credit: Niels Heinen of the Google security team References: http://ofbiz.apache.org/download.html#vulnerabilities
[CVE-2019-10073] Apache OFBiz XSS vulnerability in the "ecommerce" component
Severity: Important Vendor: The Apache Software Foundation Versions Affected: OFBiz 16.11.01 to 16.11.05 Description: The "Blog", "Forum", "Contact Us" screens of the template "ecommerce" application bundled in Apache OFBiz are weak to Stored XSS attacks. Mitigation: Upgrade to 16.11.06 or manually apply the following commits on branch 16.11: 1858438, 1858543, 1860595 and 1860616 Credit: Vikash Patnaik Dinesh Kumar Mohanty References: http://ofbiz.apache.org/download.html#vulnerabilities
[ANNOUNCE] Apache OFBiz 16.11.06 released
The Apache OFBiz community is pleased to announce the new release "Apache OFBiz 16.11.06". Apache OFBiz® is an open source product for the automation of enterprise processes that includes framework components and business applications. http://ofbiz.apache.org/ "Apache OFBiz 16.11.06" is the latest and greatest release of OFBiz; for more details of the changes introduced with this new version please refer to http://ofbiz.apache.org/release-notes-16.11.06.html The release file can be downloaded following the instructions in the OFBiz download page: http://ofbiz.apache.org/download.html The OFBiz community.
Default transaction timeout on screen widget
Hi all,
Since I increase the sensibility of error message [1], we have on
different screen that take some time to rendering an error throw due to
transaction timeout.
By default each screen is rendering with the default timeout (60s) that
isn't enough when you have big data compilation or some external service
latency.
Of course it's possible to analyze each case with purpose to increase
the screen velocity or set a transaction-timeout on screen definition,
but as first easy step what do you think if we add a default transaction
timeout for screen to 10 minutes with possibility to override by
properties ?
Example:
*
framework/widget/src/main/java/org/apache/ofbiz/widget/model/ModelScreen.java
@@ -122,7 +123,7 @@ public class ModelScreen extends ModelWidget {
// wrap the whole screen rendering in a transaction, should
improve performance in querying and such
Map parameters =
UtilGenerics.cast(context.get("parameters"));
boolean beganTransaction = false;
- int transactionTimeout = -1;
+ int transactionTimeout =
UtilProperties.getPropertyAsInteger("widget",
"widget.transaction.timeout.default", 600);
if (parameters != null) {
String transactionTimeoutPar =
parameters.get("TRANSACTION_TIMEOUT");
if (transactionTimeoutPar != null) {
@@ -152,12 +153,7 @@ public class ModelScreen extends ModelWidget {
// If transaction timeout is present, use it to start the
transaction
// If transaction timeout is set to zero, no transaction
is started
if (useTransaction) {
- if (transactionTimeout < 0) {
- beganTransaction = TransactionUtil.begin();
- }
- if (transactionTimeout > 0) {
- beganTransaction =
TransactionUtil.begin(transactionTimeout);
- }
+ beganTransaction =
TransactionUtil.begin(transactionTimeout);
}
// render the screen, starting with the top-level section
***
Any remarks ?
In parallel i will investigate why the error message catch is so sensible.
Nicolas
[1] http://svn.apache.org/viewvc?view=revision=1856175
--
logoNrd
