I guess people here are aware of it, but for the sake of even mire
completeness: the official security document for log4j2 has been amended:
- currently only version 2.16.0 and, if one absolutely needs to run on
Java 7, version 2.12.2 really fix the problems. The originally suggested
version 2.15.0 does not suffice. To reduce confusion: although the
version number 2.12.2 is much smaller than 2.16.0, it is a new backport
of the fix to the latest version, that was compatible with Java 7.
- the system property / environment variable workaround to suppress
message lookups is no longer recommended, because it is incomplete
- if one absolutely can not update or not fast enough, removing the
Log4j JndiLookup class from the log4j core jar file and all other places
where it might have beend deployed in an application is still assumed to
be a good workaround. Plus restart of course.
Best regards,
Rainer
Am 16.12.2021 um 17:03 schrieb Christopher Schultz:
Mark,
Adding that the below message also applies for both CVE-2021-45046 and
CVE-2021-4104 as well as the originally-mentioned 2021-44228, for
completeness.
-chris
On 12/14/21 04:51, Mark Thomas wrote:
The following represents the current understanding of the Apache
Tomcat security team at the time this announcement was issued. There
is a lot of security research being focussed on log4j2 at the moment
and it is probable that additional information will emerge.
Currently supported Tomcat versions (8.5.x, 9.0.x, 10.0.x and 10.1.x)
have no dependency on any version of log4j.
Web applications deployed on Tomcat may have a dependency on log4j.
You should seek support from your application vendors on how best to
address this vulnerability.
Tomcat 8.0.x and earlier as well as the first few releases of 8.5.x
(8.5.3 and earlier) provided optional support for switching Tomcat's
internal logging to log4j 1.x. Anyone one using these very old (5+
years), unsupported versions of Tomcat that switched to using log4j
1.x may need to address this vulnerability as log4j 1.x may be
affected in some (probably rarely used) configurations. Regardless,
they'll need to address the Tomcat vulnerabilities that have been made
public in those 5+ years.
It is possible to configure Tomcat to use log4j 2.x for Tomcat's
internal logging. This requires explicit configuration and the
addition of the log4j 2.x library. Anyone who has switched Tomcat's
internal logging to log4j 2.x is likely to need to address this
vulnerability.
In most cases, disabling the problematic feature will be the simplest
solution. Exactly how to do that depends on the exact version of
log4j2 being used. Details are provided on the log4j2 security page [1].
If not already subscribed, you may wish to follow the ASF
announcements mailing list [2] where any significant updates from the
logging project will be posted.
If you have any questions regarding this issue or how to mitigate it,
please direct them to the Apache Tomcat Users mailing list [3].
The Apache Tomcat Security Team
[1] https://logging.apache.org/log4j/2.x/security.html
[2]
https://www.apache.org/foundation/mailinglists.html#foundation-announce
[3] https://tomcat.apache.org/lists.html#tomcat-users
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
