[jira] [Commented] (OFBIZ-11407) Upgrade Tomcat from 9.0.29 to 9.0.31 (CVE-2020-1938)

["ASF subversion and git services (Jira)" <ji...@apache.org>]

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

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

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


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