You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by jo...@wellsfargo.com.INVALID on 2021/12/13 16:51:16 UTC
log4j CVE general question
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?
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://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228>: 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://issues.apache.org/jira/browse/LOG4J2-3201 and https://issues.apache.org/jira/browse/LOG4J2-3198
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<ma...@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.
RE: log4j CVE general question
Posted by jo...@wellsfargo.com.INVALID.
Ok, so I have been given clearance to share the stance that we are taking with log4j. We have contacted Apache Security and are awaiting a response.
Before making a final decision around log4j 1.x, consider the following:
-Initially, 1.x wasn’t assessed for the vulnerability, because, it is end of life, so many points of guidance did not assess it and exclude it from their advisories.
-The situation with 1.x is morphing, modifications to the payload may result in RCE or server-side lookups, there are also circumstances were 1.x is vulnerable:
-Log4j 1.x may be impacted by CVE-2021-44228 in a number of conditions, such as when the configuration uses JNDI, which may have been enabled.
-It's possible to use the 1.x Appender to load strings from a remote server. If you sent TopicBindingName or TopicConnectionFactoryBindingName to values that JDNI can handle, which is a configuration issue that needs to be investigated by teams using 1.x, but a lower priority than the risk of 2.x exploitation which is not configuration-dependent.
-Log4j .x is End of Life, and has other security vulnerabilities that will not be fixed, i.e (CVE-2019-17571) that should be assessed when judging their risk.
Our recommendation is to migrate from 1.x as a P2 priority, behind your 2.x patching efforts. Migration guide: https://logging.apache.org/log4j/2.x/manual/migration.html
Thanks. Just trying to help and practice good stewardship in the Tomcat community. :-D
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: jonmcalexander@wellsfargo.com.INVALID
> <jo...@wellsfargo.com.INVALID>
> Sent: Monday, December 13, 2021 11:48 AM
> To: users@tomcat.apache.org
> Subject: RE: log4j CVE general question
>
> I understand Chris. I guess I was looking to see if he had contact info for
> anyone on that particular project. I know it's not like a "company".
>
> Thanks though!
>
> 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: 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, jonmcalexander@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
> > >
> > >
> >
> jonmcalexander@wellsfargo.com<ma...@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-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
>
> B
> KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
> KKKKKKKKKKCB [ X ܚX KK[XZ[
>
> \ \ ][ X ܚX P X ]
> \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[
>
> \ \ Z[ X ]
> \X K ܙ B
Re: log4j CVE general question
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Jon,
On 12/13/21 12:48, jonmcalexander@wellsfargo.com.INVALID wrote:
> I understand Chris. I guess I was looking to see if he had contact
> info for anyone on that particular project. I know it's not like a
> "company".
It's just like Tomcat: they have a public mailing list.
-chris
>> -----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, jonmcalexander@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
>>>
>>>
>> jonmcalexander@wellsfargo.com<ma...@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: log4j CVE general question
Posted by jo...@wellsfargo.com.INVALID.
I understand Chris. I guess I was looking to see if he had contact info for anyone on that particular project. I know it's not like a "company".
Thanks though!
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: 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, jonmcalexander@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
> >
> >
> jonmcalexander@wellsfargo.com<ma...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
Re: log4j CVE general question
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Jon,
On 12/13/21 11:51, jonmcalexander@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://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228>: 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://issues.apache.org/jira/browse/LOG4J2-3201 and https://issues.apache.org/jira/browse/LOG4J2-3198
>
> 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<ma...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org