[jira] [Commented] (OFBIZ-11407) Upgrade Tomcat from 9.0.29 to 9.0.31 (CVE-2020-1938)
[ https://issues.apache.org/jira/browse/OFBIZ-11407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487027#comment-17487027 ] ASF subversion and git services commented on OFBIZ-11407: - Commit b2c0a4a64471343f1294a1168a47d92257040d7f in ofbiz-framework's branch refs/heads/release22.01 from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=b2c0a4a ] Fixed: Possible authenticated attack related to Tomcat CVE-2020-1938 (OFBIZ-12558) Despite OFBIZ-11407, the 2 values secretRequired and especially allowedRequestAttributesPattern are commented out because of OFBIZ-12558 The Tomcat default values will be used as recommended by https://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html#Introduction This is in relation with https://tomcat.apache.org/security-9.html#Fixed_in_Apache_Tomcat_9.0.31 and https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html#Connectors 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]
[jira] [Commented] (OFBIZ-11407) Upgrade Tomcat from 9.0.29 to 9.0.31 (CVE-2020-1938)
[ https://issues.apache.org/jira/browse/OFBIZ-11407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 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 " 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,
[jira] [Commented] (OFBIZ-11407) Upgrade Tomcat from 9.0.29 to 9.0.31 (CVE-2020-1938)
[ https://issues.apache.org/jira/browse/OFBIZ-11407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487029#comment-17487029 ] ASF subversion and git services commented on OFBIZ-11407: - Commit b0b02034eecf8d18ac7ea12f34469ec511269fa0 in ofbiz-framework's branch refs/heads/trunk from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=b0b0203 ] Fixed: Remote Code Execution (File Upload) Vulnerability (OFBIZ-11948) Lion Tree 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 " 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
[jira] [Commented] (OFBIZ-11407) Upgrade Tomcat from 9.0.29 to 9.0.31 (CVE-2020-1938)
[ https://issues.apache.org/jira/browse/OFBIZ-11407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 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 " 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,
[jira] [Commented] (OFBIZ-11407) Upgrade Tomcat from 9.0.29 to 9.0.31 (CVE-2020-1938)
[ https://issues.apache.org/jira/browse/OFBIZ-11407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487032#comment-17487032 ] ASF subversion and git services commented on OFBIZ-11407: - Commit 5b1843f1c068b93d928420c80c1a8301990ef580 in ofbiz-framework's branch refs/heads/trunk from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=5b1843f ] Fixed: Possible authenticated attack related to Tomcat CVE-2020-1938 (OFBIZ-12558) Despite OFBIZ-11407, the 2 values secretRequired and especially allowedRequestAttributesPattern are commented out because of OFBIZ-12558 The Tomcat default values will be used as recommended by https://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html#Introduction This is in relation with https://tomcat.apache.org/security-9.html#Fixed_in_Apache_Tomcat_9.0.31 and https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html#Connectors 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]
[jira] [Commented] (OFBIZ-11407) Upgrade Tomcat from 9.0.29 to 9.0.31 (CVE-2020-1938)
[ https://issues.apache.org/jira/browse/OFBIZ-11407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487022#comment-17487022 ] ASF subversion and git services commented on OFBIZ-11407: - Commit 4ab4b15ade3fb544de25d259123c0ec2c5ce9df7 in ofbiz-framework's branch refs/heads/release18.12 from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=4ab4b15 ] Fixed: Possible authenticated attack related to Tomcat CVE-2020-1938 (OFBIZ-12558) Despite OFBIZ-11407, the 2 values secretRequired and especially allowedRequestAttributesPattern are commented out because of OFBIZ-12558 The Tomcat default values will be used as recommended by https://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html#Introduction This is in relation with https://tomcat.apache.org/security-9.html#Fixed_in_Apache_Tomcat_9.0.31 and https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html#Connectors Thanks: Lion Tree for report Conflicts handled by hand in framework/catalina/ofbiz-component.xml > 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
[jira] [Commented] (OFBIZ-11407) Upgrade Tomcat from 9.0.29 to 9.0.31 (CVE-2020-1938)
[
https://issues.apache.org/jira/browse/OFBIZ-11407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047698#comment-17047698
]
Jacques Le Roux commented on OFBIZ-11407:
-
I just tried for you. I removed
{code:java}
dependencies {
pluginLibsCompile 'org.apache.tomcat.embed:tomcat-embed-websocket:9.0.27'
}
{code}
got:
{noformat}
> Task :compileJava
C:\projectsASF\Git\ofbiz-framework\plugins\example\src\main\java\org\apache\ofbiz\example\ExampleServices.java:25:
error: package javax.websocket does not exist
import javax.websocket.Session;
[...etc...]
{noformat}
> 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
> Fix For: Upcoming Branch
>
>
> 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.3.4#803005)
[jira] [Commented] (OFBIZ-11407) Upgrade Tomcat from 9.0.29 to 9.0.31 (CVE-2020-1938)
[ https://issues.apache.org/jira/browse/OFBIZ-11407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047611#comment-17047611 ] Pierre Smits commented on OFBIZ-11407: -- Jacques, I don't know I am concerned that this will start another discussion on dev.ml like we had recently with the 'Should we clean labels'. > 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 > Fix For: Upcoming Branch > > > 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.3.4#803005)
[jira] [Commented] (OFBIZ-11407) Upgrade Tomcat from 9.0.29 to 9.0.31 (CVE-2020-1938)
[ https://issues.apache.org/jira/browse/OFBIZ-11407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047605#comment-17047605 ] Jacques Le Roux commented on OFBIZ-11407: - Pierre, You can easily answer at your own question. Simply remove the build in example plugin and launch OFBiz ;) > 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 > Fix For: Upcoming Branch > > > 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.3.4#803005)
[jira] [Commented] (OFBIZ-11407) Upgrade Tomcat from 9.0.29 to 9.0.31 (CVE-2020-1938)
[ https://issues.apache.org/jira/browse/OFBIZ-11407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047453#comment-17047453 ] Pierre Smits commented on OFBIZ-11407: -- With Commit 227ecf8023a13789a7ed739807e1d93ee7891e0c in ofbiz-plugins's the proposed upgrade is added to the 'example' plugin. Isn't this upgrade in the main ofbiz repo not also working for components in plugins? If so, there should be no need to have it explicitly in the example component, correct? > 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 > Fix For: Upcoming Branch > > > 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.3.4#803005)
[jira] [Commented] (OFBIZ-11407) Upgrade Tomcat from 9.0.29 to 9.0.31 (CVE-2020-1938)
[ https://issues.apache.org/jira/browse/OFBIZ-11407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046672#comment-17046672 ] ASF subversion and git services commented on OFBIZ-11407: - Commit 227ecf8023a13789a7ed739807e1d93ee7891e0c in ofbiz-plugins's branch refs/heads/release17.12 from Deepak Dixit [ https://gitbox.apache.org/repos/asf?p=ofbiz-plugins.git;h=227ecf8 ] Upgrade Tomcat from 9.0.29 to 9.0.31 (CVE-2020-1938) (OFBIZ-11407) tomcat-embed-websocket dependencies not updated > 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 > Fix For: Upcoming Branch > > > 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.3.4#803005)
[jira] [Commented] (OFBIZ-11407) Upgrade Tomcat from 9.0.29 to 9.0.31 (CVE-2020-1938)
[ https://issues.apache.org/jira/browse/OFBIZ-11407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044541#comment-17044541 ] ASF subversion and git services commented on OFBIZ-11407: - Commit 018ebbb26577a634fbffbf32e9afe725af429692 in ofbiz-framework's branch refs/heads/release18.12 from Michael Brohl [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=018ebbb ] Upgrade Tomcat from 9.0.29 to 9.0.31 (OFBIZ-11407) Overriding the new default property secretRequired to be not required and added the default property "secret" in the commented out section. > 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 > Fix For: Upcoming Branch > > > 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.3.4#803005)
[jira] [Commented] (OFBIZ-11407) Upgrade Tomcat from 9.0.29 to 9.0.31 (CVE-2020-1938)
[ https://issues.apache.org/jira/browse/OFBIZ-11407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044540#comment-17044540 ] ASF subversion and git services commented on OFBIZ-11407: - Commit 0ea9173e8dd83bfbf5255548079de96c82a88544 in ofbiz-framework's branch refs/heads/release17.12 from Michael Brohl [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=0ea9173 ] Upgrade Tomcat from 9.0.29 to 9.0.31 (OFBIZ-11407) Overriding the new default property secretRequired to be not required and added the default property "secret" in the commented out section. > 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 > Fix For: Upcoming Branch > > > 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.3.4#803005)
[jira] [Commented] (OFBIZ-11407) Upgrade Tomcat from 9.0.29 to 9.0.31 (CVE-2020-1938)
[ https://issues.apache.org/jira/browse/OFBIZ-11407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044521#comment-17044521 ] ASF subversion and git services commented on OFBIZ-11407: - Commit 3856b0aebe67d49d8c3810663f6c91c999f18aaa in ofbiz-framework's branch refs/heads/release18.12 from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=3856b0a ] Upgrade Tomcat from 9.0.19 to 9.0.31 (OFBIZ-11407) Backported by hand (cherry pick failed) because of CVE-2020-1938 > 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 > Fix For: Upcoming Branch > > > 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.3.4#803005)
[jira] [Commented] (OFBIZ-11407) Upgrade Tomcat from 9.0.29 to 9.0.31 (CVE-2020-1938)
[ https://issues.apache.org/jira/browse/OFBIZ-11407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044174#comment-17044174 ] Jacques Le Roux commented on OFBIZ-11407: - Since it's a high severity CVE and AJP related, I'll backport to supported release branches (R17 and R18). > 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 > Fix For: Upcoming Branch > > > 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.3.4#803005)
