-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Monday, December 13, 2021 11:39 AM
To: users@tomcat.apache.org
Subject: Re: log4j CVE general question
Jon,
On 12/13/21 11:51, jonmcalexan...@wellsfargo.com.INVALID wrote:
So, based on these entries on the log4j apache pages, I can't see that
any 1x product is vulnerable. Mark, is there some message from Apache
that we can share with those that need to know that for certain 1x
log4j is NOT vulnerable?
This is not something the Tomcat team (or Mark, individually) can really do
for you.
You should check for information from the log4j team.
Unofficially, log4j 1.x does not seem to be affected. There were some
questions about configuring it for use with a JMS appender, but it seems
those issues would be limited to having a compromised JMS server or an
injection into JNDI from another (unrelated) exploit.
-chris
News
CVE-2021-44228
The Log4j team has been made aware of a security vulnerability, CVE-2021-
44228, that has been addressed in Log4j 2.15.0.
Log4j's JNDI support has not restricted what names could be resolved.
Some protocols are unsafe or can allow remote code execution. Log4j now
limits the protocols by default to only java, ldap, and ldaps and limits the
ldap
protocols to only accessing Java primitive objects by default served on the
local host.
One vector that allowed exposure to this vulnerability was Log4j's
allowance of Lookups to appear in log messages. As of Log4j 2.15.0 this
feature is now disabled by default. While an option has been provided to
enable Lookups in this fashion, users are strongly discouraged from enabling
it.
For those who cannot upgrade to 2.15.0, in releases >=2.10, this behavior
can be mitigated by setting either the system property
log4j2.formatMsgNoLookups or the environment variable
LOG4J_FORMAT_MSG_NO_LOOKUPS to true. For releases >=2.7 and
<=2.14.1, all PatternLayout patterns can be modified to specify the message
converter as %m{nolookups} instead of just %m. For releases >=2.0-beta9
and <=2.10.0, the mitigation is to remove the JndiLookup class from the
classpath: zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class.
Fixed in Log4j 2.15.0
CVE-2021-44228<https://urldefense.com/v3/__https://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2021-
44228__;!!F9svGWnIaVPGSwU!74bXJbpgx_hbZXhDbugIcTGP5lu3n4862EH5m
3nzPf6zeN_vbTWY0WIHuhFmP_EenqW0-rM$ >: Apache Log4j2 JNDI
features do not protect against attacker controlled LDAP and other JNDI
related endpoints.
Severity: Critical
Base CVSS Score: 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Versions Affected: all log4j-core versions >=2.0-beta9 and <=2.14.1
Descripton: Apache Log4j <=2.14.1 JNDI features used in configuration, log
messages, and parameters do not protect against attacker controlled LDAP
and other JNDI related endpoints. An attacker who can control log messages
or log message parameters can execute arbitrary code loaded from LDAP
servers when message lookup substitution is enabled. From log4j 2.15.0, this
behavior has been disabled by default.
Mitigation: In releases >=2.10, this behavior can be mitigated by setting
either the system property log4j2.formatMsgNoLookups or the environment
variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. For releases >=2.7
and <=2.14.1, all PatternLayout patterns can be modified to specify the
message converter as %m{nolookups} instead of just %m. For releases
=2.0-beta9 and <=2.10.0, the mitigation is to remove the JndiLookup class
from the classpath: zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class.
Credit: This issue was discovered by Chen Zhaojun of Alibaba Cloud Security
Team.
References:
https://urldefense.com/v3/__https://issues.apache.org/jira/browse/LOG4
J2-
3201__;!!F9svGWnIaVPGSwU!74bXJbpgx_hbZXhDbugIcTGP5lu3n4862EH5m3
nzPf
6zeN_vbTWY0WIHuhFmP_EezMJYN6o$ and
https://urldefense.com/v3/__https://issues.apache.org/jira/browse/LOG4
J2-
3198__;!!F9svGWnIaVPGSwU!74bXJbpgx_hbZXhDbugIcTGP5lu3n4862EH5m3
nzPf
6zeN_vbTWY0WIHuhFmP_EenSYqOaM$
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
jonmcalexan...@wellsfargo.com<mailto:jonmcalexan...@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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
