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