Overview
OFbiz is an enterprise-grade multi-layer distributed E-Commerce web framework that is across platforms and databases. It is a well-known open-source project based on the latest J2EEXML standard. OFBiz is a widely used e-commerce platform in many industries.
In Apache OFBiz recent release, a few deserialization vulnerabilities were discovered. The first is CVE-2021-26295 published on March 22nd in release version 17.12.06. In Apache’s fix to CVE-2021-26295, two additional vulnerabilities (CVE-2021-29200 and CVE-2021-30128) were found by different security research organizations. These two new vulnerabilities allow an unauthenticated user to perform an RCE attack and they have been fixed in the OFbiz release version 17.12.07.
This blog analyzes both CVE-2021-29200 and CVE-2021-30128 and reveals the discovery process.
Vulnerability Information:
CVE information: https://nvd.nist.gov/vuln/detail/CVE-2021-29200; https://nvd.nist.gov/vuln/detail/CVE-2021-30128
Severity: Critical with CVSS score 9.8
Affected versions: prior to 17.12.07
Solution: please download and upgrade to the latest version of Apache OFBiz:
https://downloads.apache.org/ofbiz/apache-ofbiz-17.12.07.zip
Vulnerability Analysis
On March 22nd a security vendor issued a risk notice for the Apache OFBiz CVE-2021-26295 deserialization vulnerability. Apache then issued a fix for this vulnerability: https://github.com/apache/ofbiz-framework/commit/af9ed4e.
The code fix is to “blacklist” RMI server to prevent it from being exploited. However, in the published fix (see Screen Shot 1), security analysts discovered another vulnerability and verified with a PoC code.
Screen Shot 1: Fix to CVE-2021-26295
We know typically the rewriting the resolveClass method can be used to prevent deserialization vulnerabilities. The code fix for CVE-2021-26295 followed the common practice to rewrite the resolveClass by excluding “java.rmi.server” from the Class.
The complete SafeObjectInputStream code is shown in the Screen Shot 2. The SafeObjectInputStream class uses the blacklist and whitelist to prevent the deserialization vulnerabilities. But there was a logical loophole in setting the conditions for the blacklist.
Screen Shot 2: SafeObjectInputStream Class
In line 67, the code checks the className and returns “null” if it contains the “java.rmi.server”.
In line 72 to line 77, the code uses “return null” instead of issuing InvalidClassException to handle an exception. This oversight inadvertently created a logic error where the following whitelist check will not be performed and exposed the “file upload” vulnerability.
This security loophole in the fix code caused another vulnerability! The security researcher was able to use the following method to validate it.
Based on the two “return nulls” in the resolveClass method of the SafeObjectInputStream class, the researcher figured out that the two PoCs which “java.rmi.server” and “org.apache.commons.fileupload” can be used are corresponding to JRMPClient and FileUpload1 of ysoserial.
OFBiz has upgraded the commons-fileupload to version 1.3.3, therefore there is no loophole in its default configuration. But if the SERIALIZABLE_PROPERTY is configured, the loophole will occur.
Screen Shot 3: Two PoC Examples
JRMPClient PoC can be used to exploit the vulnerability. First, use ysoserial’s JRMPListener to start a JRMP port, and send JRMPClient PoC to OFBiz and then let the OFBiz server requests a malicious payload from the JRMP port to perform the exploitation.
NVD (National Vulnerability Database) also accepted this vulnerability as CVE-2021-29200. Apache also acknowledged it and provided the following code to resolve this vulnerability:
Screen Shot 4: Apache Fix Code to CVE-2021-29200
OFBiz made three changes in the fix: 1 and 2: The “return null” codes of “java.rmi.server” and “org.apache.commons.fileupload” were changed to “throw exceptions”. 3. Expanded the scope of the previous “java.rmi.server” to “java.rmi”. The reason for the expansion of the blacklist scope was not clear at the time. Soon after, It turned out someone announced a 0day in the low version of weblogic jdk, which used java.rmi.MarshalledObject as the secondary deserialization to bypass the blacklist check. The 3rd fix was trying to address the vulnerability in both java.rmi.server and java.rmi.MarshalledObject.
Apache asked the security researcher to validate the proposed fix to CVE-2021-29200.
Screen Shot 5: The loophole that causes CVE-2021-30128
When the researchers reviewed the proposed fix, they identified a potential logical vulnerability in the code (see Screen Shot 5). The whitelistPattern.matcher is used to match the class name, but the starting position of the class name is not defined which could be a security risk. If the class name is xxx.java.xxx, it will also pass the whitelist check. Since the researcher couldn’t find a class with the class name as xxx.java.xxx at that time to validate the risk, this proposed code change passed the security check. Not long after, a security researcher from Alibaba confirmed this code oversight is a real vulnerability. Alibaba filed this new CVE with the number CVE-2021-30128.
The analysis of these three related vulnerabilities shows how easy to introduce a 0-day vulnerability in a typical software development process. It also reveals how hacker can take advantage of potential logical errors to exploit any potential vulnerability in the system. Automated security tools can help to minimize the exposure of software vulnerability by integrate security in the development process and automate pen testing as a security validation on each check points throughout the development process.