Unless there are objections, I'm planning on sending a follow-up to the
original email to state (in summary)
- more CVEs have been identified
- given the amount of attention focussed on this there may be further
CVEs
- previous advice regarding the impact for Tomcat is essentially
unchanged
- follow the log4j advice on mitigation which is changing over time -
mitigation via configuration is unlikely to be sufficient
- monitor log4j for further updates
Mark
16 Dec 2021 22:49:59 Rainer Jung <rainer.j...@kippdata.de>:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org