You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ofbiz.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2022/02/04 11:32:00 UTC

[jira] [Commented] (OFBIZ-12080) Secure the uploads

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

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

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

Fixed: Remote Code Execution (File Upload) Vulnerability (OFBIZ-11948)

Lion Tree <li...@gmail.com> has reported us that
"CVE-2020-1938 is not fully fixed".

Though it was fixed by OFBIZ-11407, it still possible for an authenticated user
to upload a webshell included in an image using one of the upload possibilities
in OFBiz. That is not new and covered by OFBIZ-12080 "Secure the uploads", but
was still incomplete.

This enforces the secured uploads by
* checking in SecuredUpload::isValidImageFile that a webshell is not embedded in
an image.
* Keeping only "<%" as a denied token for JSP webshells, instead of currently
"<%@ page"
* Adds "application/text/x-ruby" to SecuredUpload::isExecutable

Also
* Adds "<jsp", and "<?" for PHP. Even if OFBiz does not use PHP at all,
it's often installed on servers.
* Removes "import=\"java" and "runtime.getruntime().exec(". They are no
longer useful since "<%" and "<jsp" block them.
* Remove php token since I'll put "<?" in.
* Adds "#!", rather than adding other shebangs like perl,python and ruby

This will make deniedWebShellTokens more understandable.

But I'm conscious that despite SecuredUpload::isExecutableI I still need to
better handle encoded webshells. I'll do that soon in a second approach.

I'll also certainly more prune PHP related tokens.

Thanks: Lion Tree for report


> Secure the uploads
> ------------------
>
>                 Key: OFBIZ-12080
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-12080
>             Project: OFBiz
>          Issue Type: Sub-task
>          Components: ALL APPLICATIONS, ALL PLUGINS
>    Affects Versions: Trunk
>            Reporter: Jacques Le Roux
>            Assignee: Jacques Le Roux
>            Priority: Major
>             Fix For: 17.12.07, 18.12.01
>
>         Attachments: OFBIZ-12080.patch
>
>
> 2020/08/10 the OFBiz security team received a security report by Harshit Shukla <ha...@gmail.com>, roughly it was (quoting part of it to simplify):
> bq. I have identified a Remote Code Execution (RCE) Vulnerability. The reason behind this RCE is lack of file extension check at catalog/control/UploadCategoryImage?productCategoryId=CATALOG1_BEST_SELL&pload_file_type=category
> Using this post-auth RCE in OFBiz demos, Harshit was able to get some AWS credentials by uploading a webshell (based on [0]). By security, it was then decided by the Infra and OFBiz security teams to shut down the demos.
> After I decided we needed to secure all our uploads and not only checking extensions, I began to work on the vulnerablity. During this work I discovered, according to [1] and [2], that these AWS credentials are so far considered harmless.
> This post-auth RCE relies on the demo data. In our documentation[3], we warn our users to not use the demo data. Notably because they allow to sign in as an admin!
> After discussing these elements with Mark J Cox (VP of ASF security team[4]) we in common decided that no CVE was necessary.
> [0] https://github.com/tennc/webshell/blob/master/fuzzdb-webshell/jsp/cmd.jsp
> [1] https://ibreak.software/2020/04/what-are-these-reserved-set-of-security-credentials-in-aws/
> [2] https://twitter.com/SpenGietz/status/1104198404471631872
> [3] https://cwiki.apache.org/confluence/display/OFBIZ/How+to+secure+your+deployment
> [4] https://awe.com/mark/history/index.html



--
This message was sent by Atlassian Jira
(v8.20.1#820001)