Your submission was sent successfully! Close

CVE-2020-1938

Published: 24 February 2020

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. In Apache Tomcat 9.0.0.M1 to 9.0.0.30, 8.5.0 to 8.5.50 and 7.0.0 to 7.0.99, 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. This vulnerability report identified a mechanism that allowed: - returning arbitrary files from anywhere in the web application - 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. It is important to note that mitigation is only required if an AJP port is accessible to untrusted users. 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, 8.5.51 or 7.0.100 or later. A number of changes were made to the default AJP Connector configuration in 9.0.31 to harden the default configuration. It is likely that users upgrading to 9.0.31, 8.5.51 or 7.0.100 or later will need to make small changes to their configurations.

Mitigation

mdeslaur> In environments where the AJP connector is enabled, care should
mdeslaur> be taken to not expose the AJP port to attackers, either by
mdeslaur> using a firewall to block the AJP port, or by binding it to
mdeslaur> localhost by using address="127.0.0.1" in the AJP configuration.
Priority

Low

CVSS 3 base score: 9.8

Status

Package Release Status
tomcat7
Launchpad, Ubuntu, Debian
bionic Needed

eoan Does not exist

focal Does not exist

groovy Does not exist

hirsute Does not exist

impish Does not exist

jammy Does not exist

precise Does not exist

trusty Ignored

upstream Needs triage

xenial Ignored
(end of standard support, was needed)
tomcat8
Launchpad, Ubuntu, Debian
bionic Needed

eoan Does not exist

focal Does not exist

groovy Does not exist

hirsute Does not exist

impish Does not exist

jammy Does not exist

precise Does not exist

trusty Does not exist

upstream Needs triage

xenial Needed

tomcat9
Launchpad, Ubuntu, Debian
bionic Needed

eoan Ignored
(reached end-of-life)
focal Not vulnerable
(9.0.31-1)
groovy Not vulnerable
(9.0.31-1)
hirsute Not vulnerable
(9.0.31-1)
impish Not vulnerable
(9.0.31-1)
jammy Not vulnerable
(9.0.31-1)
precise Does not exist

trusty Does not exist

upstream
Released (9.0.31-1)
xenial Does not exist

Notes

AuthorNote
mdeslaur
In Ubuntu packages, the AJP connector is disabled by default,
so unless specifically enabled by an admin, deployments made
using the package are not vulnerable to this issue.

One of the upstream fixes for this issue renames the
requiredSecret parameter to secret and adds a secretRequired
parameter that defaults to "true". Adding this change to stable
releases will result in servers failing to start until the
administrator either changes secretRequired to "false", or
configures an adequate secret. Apache starting supporting a
secret in mod_proxy_ajp starting with 2.4.42, which means to
enable a secret we will have to issue Apache updates with
the backported secret support.

References

Bugs