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)