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
