You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2020/02/24 12:47:18 UTC
[SECURITY] CVE-2020-1938 AJP Request Injection and potential Remote
Code Execution
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/security-7.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
AW: [SECURITY] CVE-2020-1938 AJP Request Injection and
potentialRemote Code Execution
Posted by js84 <ao...@aon.at>.
Hello!
Proposed work-arounds don’t cover possible vulnerability over a reverse proxy: Can an attacker abuse AJP vulnerability when access is mapped by mod_jk or mod_proxy_ajp?
Kind regards,
Johann
Von: Mark Thomas
Gesendet: Montag, 2. März 2020 10:11
An: users@tomcat.apache.org
Betreff: Re: [SECURITY] CVE-2020-1938 AJP Request Injection and potentialRemote Code Execution
On 01/03/2020 23:34, Stefan Mayr wrote:
> Am 24.02.2020 um 13:47 schrieb Mark Thomas:
>> CVE-2020-1938 AJP Request Injection and potential Remote Code Execution
>>
>> Severity: High
>>
>> ...
>> - 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.
>
> Is this a bug which is or will be fixed or is this a fundamental design
> flaw of AJP which cannot be fixed? So to trust or not to trust are the
> only options?
Not really.
The ability for an AJP client to obtain arbitrary files from the web
application has been blocked by default.
The ability for an AJP client to trigger the processing of any file from
the web application as a JSP has been blocked by default.
The above two points are, essentially, CVE-2020-1928.
If the web application depends on knowing the true user IP address then
Tomcat has to trust the AJP client to provide that data.
If the web application depends on the reverse proxy (the AJP client)
performing authentication and passing the authenticated identify to
Tomcat then Tomcat has to trust that the reverse proxy does this correctly.
And so on for all the other user information that the AJP protocol can
pass to Tomcat.
How Tomcat decides to trust the AJP client is a decision for the system
administrator. Options include:
- have the AJP Connector listen on a non-public IP address that only the
reverse proxy can access
- use firewall rules to limit connections to the AJP port to trusted
hosts
- configure a shared secret in the reverse proxy and the AJP Connector
Mark
>
> Thanks,
>
> Stefan Mayr
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: [SECURITY] CVE-2020-1938 AJP Request Injection and
potentialRemote Code Execution
Posted by Mark Thomas <ma...@apache.org>.
On 02/03/2020 10:12, js84 wrote:
> Hello!
>
> Proposed work-arounds don’t cover possible vulnerability over a reverse proxy:
Correct.
> Can an attacker abuse AJP vulnerability when access is mapped by mod_jk or mod_proxy_ajp?
No.
Mark
>
> Kind regards,
> Johann
>
> Von: Mark Thomas
> Gesendet: Montag, 2. März 2020 10:11
> An: users@tomcat.apache.org
> Betreff: Re: [SECURITY] CVE-2020-1938 AJP Request Injection and potentialRemote Code Execution
>
> On 01/03/2020 23:34, Stefan Mayr wrote:
>> Am 24.02.2020 um 13:47 schrieb Mark Thomas:
>>> CVE-2020-1938 AJP Request Injection and potential Remote Code Execution
>>>
>>> Severity: High
>>>
>>> ...
>>> - 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.
>>
>> Is this a bug which is or will be fixed or is this a fundamental design
>> flaw of AJP which cannot be fixed? So to trust or not to trust are the
>> only options?
>
> Not really.
>
> The ability for an AJP client to obtain arbitrary files from the web
> application has been blocked by default.
>
> The ability for an AJP client to trigger the processing of any file from
> the web application as a JSP has been blocked by default.
>
> The above two points are, essentially, CVE-2020-1928.
>
> If the web application depends on knowing the true user IP address then
> Tomcat has to trust the AJP client to provide that data.
>
> If the web application depends on the reverse proxy (the AJP client)
> performing authentication and passing the authenticated identify to
> Tomcat then Tomcat has to trust that the reverse proxy does this correctly.
>
> And so on for all the other user information that the AJP protocol can
> pass to Tomcat.
>
> How Tomcat decides to trust the AJP client is a decision for the system
> administrator. Options include:
>
> - have the AJP Connector listen on a non-public IP address that only the
> reverse proxy can access
> - use firewall rules to limit connections to the AJP port to trusted
> hosts
> - configure a shared secret in the reverse proxy and the AJP Connector
>
> Mark
>
>
>
>
>>
>> Thanks,
>>
>> Stefan Mayr
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [SECURITY] CVE-2020-1938 AJP Request Injection and potential
Remote Code Execution
Posted by Mark Thomas <ma...@apache.org>.
On 01/03/2020 23:34, Stefan Mayr wrote:
> Am 24.02.2020 um 13:47 schrieb Mark Thomas:
>> CVE-2020-1938 AJP Request Injection and potential Remote Code Execution
>>
>> Severity: High
>>
>> ...
>> - 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.
>
> Is this a bug which is or will be fixed or is this a fundamental design
> flaw of AJP which cannot be fixed? So to trust or not to trust are the
> only options?
Not really.
The ability for an AJP client to obtain arbitrary files from the web
application has been blocked by default.
The ability for an AJP client to trigger the processing of any file from
the web application as a JSP has been blocked by default.
The above two points are, essentially, CVE-2020-1928.
If the web application depends on knowing the true user IP address then
Tomcat has to trust the AJP client to provide that data.
If the web application depends on the reverse proxy (the AJP client)
performing authentication and passing the authenticated identify to
Tomcat then Tomcat has to trust that the reverse proxy does this correctly.
And so on for all the other user information that the AJP protocol can
pass to Tomcat.
How Tomcat decides to trust the AJP client is a decision for the system
administrator. Options include:
- have the AJP Connector listen on a non-public IP address that only the
reverse proxy can access
- use firewall rules to limit connections to the AJP port to trusted
hosts
- configure a shared secret in the reverse proxy and the AJP Connector
Mark
>
> Thanks,
>
> Stefan Mayr
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [SECURITY] CVE-2020-1938 AJP Request Injection and potential
Remote Code Execution
Posted by Stefan Mayr <st...@mayr-stefan.de>.
Am 24.02.2020 um 13:47 schrieb Mark Thomas:
> CVE-2020-1938 AJP Request Injection and potential Remote Code Execution
>
> Severity: High
>
> ...
> - 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.
Is this a bug which is or will be fixed or is this a fundamental design
flaw of AJP which cannot be fixed? So to trust or not to trust are the
only options?
Thanks,
Stefan Mayr
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org