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

Reply via email to