You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "James H. H. Lampert" <ja...@touchtonecorp.com.INVALID> on 2021/12/10 22:17:29 UTC
CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?
A customer brought this to my attention:
https://www.randori.com/blog/cve-2021-44228/
I have no idea how (or if) Tomcat is affected. I have only the vaguest
idea what this vulnerability even *is.*
Can anybody here shed any light?
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?
Posted by jo...@wellsfargo.com.INVALID.
If you aren't able to get the "fixed" version of the jar that fixes the vulnerability, I would suggest adding this to your Java Options for Tomcat:
-Dlog4j2.formatMsgNoLookups=true
Thanks,
Dream * Excel * Explore * Inspire
Jon McAlexander
Infrastructure Engineer
Asst Vice President
Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions
8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508
jonmcalexander@wellsfargo.com
This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
> -----Original Message-----
> From: James H. H. Lampert <ja...@touchtonecorp.com.INVALID>
> Sent: Friday, December 10, 2021 4:17 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect
> Tomcat?
>
> A customer brought this to my attention:
>
> https://urldefense.com/v3/__https://www.randori.com/blog/cve-2021-
> 44228/__;!!F9svGWnIaVPGSwU!4F2Gxy74aEjsyAmQbarXs0sh-
> EMIt2eM6h6liBLnKEwxjqWAPfIMcp1Od6nSrgSx9n0rFIs$
>
> I have no idea how (or if) Tomcat is affected. I have only the vaguest idea
> what this vulnerability even *is.*
>
> Can anybody here shed any light?
>
> --
> JHHL
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
All,
On 12/11/21 03:18, Mark Thomas wrote:
> On 10/12/2021 22:17, James H. H. Lampert wrote:
>> A customer brought this to my attention:
>>
>> https://www.randori.com/blog/cve-2021-44228/
>>
>> I have no idea how (or if) Tomcat is affected. I have only the vaguest
>> idea what this vulnerability even *is.*
>>
>> Can anybody here shed any light?
>
> Currently supported Tomcat versions (8.5.x, 9.0.x, 10.0.x and 10.1.x)
> have no dependency on log4j.
>
> Applications may have a dependency on log4j. You should seek support
> from your application vendors on how best to address this vulnerability
> although disabling the vulnerable feature is likely to be the simplest
> solution.
>
> Tomcat 8.0.x and earlier as well as the first few releases of 8.5.x
> provided optional support for switching Tomcat's internal logging to
> log4j 1.x. Anyone one using these very old (5+ years), unsupported
> versions that switched to using log4j 1.x is may need to address this
> vulnerability although it is not clear if log4j 1.x is affected.
This JNDI thing is a log4j 2 feature, so log4j 1.x should not be affected.
> 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 its 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. Again,
> disabling the vulnerable feature is likely to be the simplest solution.
>
> As Jon McAlexander has pointed out, adding the following to
> CATALINA_OPTS in setenv.sh / setenv.bat will disable the problematic
> feature
>
> -Dlog4j2.formatMsgNoLookups=true
Just to be clear, this only works for log4j versions 2.10 and later. If
you are running earlier than that, you may want to upgrade. Or see my
other post in this thread.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
All,
On 12/11/21 03:18, Mark Thomas wrote:
> On 10/12/2021 22:17, James H. H. Lampert wrote:
>> A customer brought this to my attention:
>>
>> https://www.randori.com/blog/cve-2021-44228/
>>
>> I have no idea how (or if) Tomcat is affected. I have only the vaguest
>> idea what this vulnerability even *is.*
>>
>> Can anybody here shed any light?
>
> Currently supported Tomcat versions (8.5.x, 9.0.x, 10.0.x and 10.1.x)
> have no dependency on log4j.
+1
> Applications may have a dependency on log4j.
+1
> -Dlog4j2.formatMsgNoLookups=true
This feature should have been disabled by default in the first place. :/
I have a few other comments for everyone who is losing their fscking
minds over this:
0. This isn't a 0-day, so stop calling it that.
1. Calm down. This isn't fscking heartbleed.
2. If you are using a recent Java version, you are fine. Remote
classloading of the type being used in these attacks was disabled by
default in Java 8u121[1] and similar-era (2017, people!) JREs.
2. Why is *anyone* allowing arbitrary outbound LDAP connections from
their servers? I'm honestly very confused and astounded that this is a
problem for network servers *at all* because any idiot should have this
in their firewall configuration:
OUTBOUND 389 -> DROP
OUTBOUND 636 -> DROP
In fact, everyone should have THIS:
OUTBOUND [stuff I actually use] -> ALLOW
OUTBOUND * -> DROP
The fact that this is causing "major problems" for the world is down to
one of two things:
1. There isn't actually any major problem at all
2. Admins everywhere don't actually know anything about security
-chris
[1] https://www.oracle.com/java/technologies/javase/8u121-relnotes.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?
Posted by Mark Thomas <ma...@apache.org>.
On 10/12/2021 22:17, James H. H. Lampert wrote:
> A customer brought this to my attention:
>
> https://www.randori.com/blog/cve-2021-44228/
>
> I have no idea how (or if) Tomcat is affected. I have only the vaguest
> idea what this vulnerability even *is.*
>
> Can anybody here shed any light?
Currently supported Tomcat versions (8.5.x, 9.0.x, 10.0.x and 10.1.x)
have no dependency on log4j.
Applications may have a dependency on log4j. You should seek support
from your application vendors on how best to address this vulnerability
although disabling the vulnerable feature is likely to be the simplest
solution.
Tomcat 8.0.x and earlier as well as the first few releases of 8.5.x
provided optional support for switching Tomcat's internal logging to
log4j 1.x. Anyone one using these very old (5+ years), unsupported
versions that switched to using log4j 1.x is may need to address this
vulnerability although it is not clear if log4j 1.x is affected.
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 its 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. Again,
disabling the vulnerable feature is likely to be the simplest solution.
As Jon McAlexander has pointed out, adding the following to
CATALINA_OPTS in setenv.sh / setenv.bat will disable the problematic feature
-Dlog4j2.formatMsgNoLookups=true
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org