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