AW: [SECURITY] CVE-2020-1938 AJP Request Injection and potentialRemote Code Execution

[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