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