[
https://issues.apache.org/jira/browse/OFBIZ-11407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17487024#comment-17487024
]
ASF subversion and git services commented on OFBIZ-11407:
---------------------------------------------------------
Commit 8c2d759847a7b22cb355a2621eb520d043591e4f in ofbiz-framework's branch
refs/heads/release22.01 from Jacques Le Roux
[ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=8c2d759 ]
Fixed: Remote Code Execution (File Upload) Vulnerability (OFBIZ-11948)
Lion Tree <liontree0...@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
> Upgrade Tomcat from 9.0.29 to 9.0.31 (CVE-2020-1938)
> ----------------------------------------------------
>
> Key: OFBIZ-11407
> URL: https://issues.apache.org/jira/browse/OFBIZ-11407
> Project: OFBiz
> Issue Type: Sub-task
> Components: framework
> Affects Versions: Trunk
> Reporter: Michael Brohl
> Assignee: Michael Brohl
> Priority: Major
>
> CVE-2020-1938 AJP Request Injection and potential Remote Code Execution
> Severity: High
> Vendor: The Apache Software Foundation
> Versions Affected:
> Apache Tomcat 9.0.0.M1 to 9.0.30
> Apache Tomcat 8.5.0 to 8.5.50
> Apache Tomcat 7.0.0 to 7.0.99
> Description:
> When using the Apache JServ Protocol (AJP), care must be taken when
> trusting incoming connections to Apache Tomcat. Tomcat treats AJP
> connections as having higher trust than, for example, a similar HTTP
> connection. If such connections are available to an attacker, they can
> be exploited in ways that may be surprising.
> Prior to Tomcat 9.0.31, 8.5.51 and 7.0.100, Tomcat shipped with an AJP
> Connector enabled by default that listened on all configured IP
> addresses. It was expected (and recommended in the security guide) that
> this Connector would be disabled if not required.
> Prior to this vulnerability report, the known risks of an attacker being
> able to access the AJP port directly were:
> - bypassing security checks based on client IP address
> - bypassing user authentication if Tomcat was configured to trust
> authentication data provided by the reverse proxy
> This vulnerability report identified a mechanism that allowed the following:
> - returning arbitrary files from anywhere in the web application
> including under the WEB-INF and META-INF directories or any other
> location reachable via ServletContext.getResourceAsStream()
> - processing any file in the web application as a JSP
> Further, if the web application allowed file upload and stored those
> files within the web application (or the attacker was able to control
> the content of the web application by some other means) then this, along
> with the ability to process a file as a JSP, made remote code execution
> possible.
> Mitigation:
> It is important to note that mitigation is only required if an AJP port
> is accessible to untrusted users.
> - If AJP support is not required, the Connector may be disabled e.g. by
> removing the AJP Connector element from the server.xml file
> - If AJP support is required, untrusted users may be prevented from
> accessing the AJP port by one or more of the following means:
> - configuring appropriate network firewall rules
> - configuring an explicit address attribute to the connector so that
> the Connector listens on a non-public interface
> - configuring a shared secret for the AJP connection
> Users wishing to take a defence-in-depth approach and block the vector
> that permits returning arbitrary files and execution as JSP may upgrade to:
> - Apache Tomcat 9.0.31 or later
> - Apache Tomcat 8.5.51 or later
> - Apache Tomcat 7.0.100 or later
> Users should note that a number of changes were made to the default AJP
> Connector configuration in these versions to harden the default
> configuration. The changes are:
> - The AJP Connector is commented out in the provided server.xml file.
> - The "requiredSecret" attribute has been renamed "secret" (the old name
> continues to work but is deprecated).
> - A new attribute "secretRequired" has been added which defaults to
> "true". When this attribute is "true", the AJP Connector will not
> start unless a shared secret has been configured.
> - The default listen address for the AJP Connector is now the loopback
> address.
> It is likely that users upgrading to 9.0.31, 8.5.51 or 7.0.100 and later
> will need to make small changes to their configurations as a result.
> References:
> [1] http://tomcat.apache.org/security-9.html
> [2] http://tomcat.apache.org/security-8.html
> [3] http://tomcat.apache.org/securit
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
