log4j

[Thomas Griffith]

Hello. I was asked if my Tomcat instances use log4j. In googling, it looks as though this isn't a Tomcat (9( default. Is there a way to confirm these instances do/don't use it? Is the bootclasspath the lib directory? I looked there for any log4j jars and see none. i alse checked the localhost/Cataliba for any log4j files and don't see anything. Thank you very much.

[Stephan van Hulst]

Do you mean Tomcat itself, or the applications you have running on Tomcat?

[Tim Moores]

Tomcat itself doesn't use log4j, it uses something Tomcat-specific called JULI (see conf/logging.properties and bin/tomcat-juli.jar).

[Stephan van Hulst]

But note that Tomcat MAY use log4j: https://logging.apache.org/log4j/2.x/log4j-appserver/index.html

[Thomas Griffith]

Ok. I see the tomcat-juli-jar present in bin and see the juli references in conf/logging.properties. So the jar is there as an option for configuration...

I don't see any log4j jars in the web apps libs. Would the only way to confirm the apps aren't using it is the source code  (import, etc)? The libs contain commons-logging-api.jar...

[Stephan van Hulst]

No. Web applications may use frameworks like SLF4J that provide a common interface for different logging libraries. log4j is one of the libraries that may be bound to SLF4J at runtime, without any reference to log4j in the code.

I think I would write an application that recursively explodes all JARs/archives in the webapps folder (and webapps referenced through the context XMLs in the config folder)  and see if they either contain classes from log4j packages, or references to log4j libraries in the manifest or module descriptor.

[Thomas Griffith]

Thanks. Yeah, I was going to view and the contents of the jars via the command line before trying to go to the recursive code route. However, although PATH is set, when I try"jar tf commons-logging-api.jar", I get a "jar is not recognized as an internal or external command..." I have a new pc and it was good on my old one.

[Stephan van Hulst]

Have you only recently set the PATH? If so, if you set it as a user environment variable it will only become available if you restart your command line, and if you set it as a system environment variable, it will only become available if you log out and in of your OS' user session.

[Tim Moores]

Something like

grep -lri log4j TOMCAT_DIR/webapps

might be a good start. There will be false positives (like commons logging, logback and slf4j, which Stephan mentioned), but it's a start to find log4j config files and libraries, and which other code and libraries use them.

If your Tomcat uses other (or more) directories for web app, repeat as necessary.

[Thomas Griffith]

Thanks. Yeah, I set the system PATH. Without logging out of the OS, javac/java ran right away, confirmed with "java -version". I then typed "java -jar commons-logging.api.jar" (as opposed to jar tf) and received "no main manifest attribute, in commons-logging-api.jar".  I'll try to log out.

I copied the commons-logging-api.jar as a zip and opened in file explorer. I see a manifest file in there and I don't see any log4j stuff...

[Stephan van Hulst]

Just mind that some applications come bundled with their own class loader that loads classes from nested jars. Be sure to scan these so called "super JARs" recursively.

[Thomas Griffith]

Tim Moores wrote:Something like

grep -lri log4j TOMCAT_DIR/webapps

might be a good start. There will be false positives (like commons logging, logback and slf4j, which Stephan mentioned), but it's a start to find log4j config files and libraries, and which other code and libraries use them.

If your Tomcat uses other (or more) directories for web app, repeat as necessary.

Thank you. Is that Linux? I'm in Windows but I'll goggle.

[Tim Holloway]

Here's the whole story in a nutshell.

Tomcat itself - as mentioned - comes set up to use the JULI logger (Java Utility Logging Interface). Only if you have built your own custom copy of Tomcat to swap out JULI for Log4J is there Log4J exposure. Not many people do, though.

Each and every webapp, however, is responsible for its own logging. And each and every webapp can use any logger or loggers that it likes. So each and every webapp will have to be individually checked for that vulnerability.

Notice that I said a single webapp can use multiple loggers. A lot of the popular application libraries such as Hibernate may have been written to use a different logger than your application code does. To bridge between the different loggers you need something like SLF4J.

Finally, the ServletContext/HttpServlet classes have a log method that routes to the container (Tomcat) logger. It's pretty useless. You can't easily reach it from business logic classes and it has no formatting/filtering abilities. It's basically just a System.out.println() to the catalina.out file. It is unaffected by the Log4J vulnerability - at least unless you've done the customized Tomcat thing. I mention if for completeness. As I said, it's practically useless.

Note that since each and every webapp defines its own loggers, each and every webapp determines its own log targets which can be anywhere on the host filesystem or network share, logging to email, pagers, and so forth and so on.

[Thomas Griffith]

Tim Holloway wrote:Each and every webapp, however, is responsible for its own logging. And each and every webapp can use any logger or loggers that it likes. So each and every webapp will have to be individually checked for that vulnerability.

Tim, thank you. I checked each webapp lib and context files. I found log classes source code but don't see anything there. commons-logging-api.jar is in the lib. Is that an issue. I viewed inside that jar and don't see any log4j. Where else would I check?

[Tim Holloway]

I'm going to have to put you at the mercy of an Internet search, but if you look, you should be able to find a tools that was designed to be able to scan a WAR/JAR file and tell you if you are at risk. I ran across it yesterday but didn't note where I saw it.

[Thomas Griffith]

Hello. It appears security team identified one of my servers as bieng at risk, although I don't run log4j in Tomcat nor the apps. I have three identical instances and strange it picked this one up. They passed along the updating to Apache 2.4.49 or later message. What does that mean exactly as I installed and running Tomcat 9 (it's own HTTP, right?). I suspect the security scan is picking up the presence of log4j jar in the Tomcat lib or something else weird. Thank you.

[Tim Holloway]

Verify that it's the Log4J risk and not some other problem and see if you can track down the program that they detected. It sounds more like they found an unrelated fault in the Apache HTTP server product. Apache HTTP does often have its own security issues, but usually an upgrade fixes them.

Tomcat contains no Log4J code itself. The only way Tomcat is exposed is if one or more webapps contains Log4J unless you have a  customized build of Tomcat.

[Thomas Griffith]

From what I've read, Tomcat and Apache Server are twp distinct things, right? Initially, I feared Tomcat was running it's http service on Apache Server but that doesn't appear to be the case.

[Tim Holloway]

The Apache Foundation presents many projects. Their flagship is the famous Apache HTTP server, which has nothing at all to do with Java.

Because it's one of the most popular web servers in the world, it often logs - and repairs - security issues of its own.

Apache also is responsible for a considerable number of Java projects, including the Jakarta series. Tomcat, in fact was originally a Jakarta project, although these days it's simply "tomcat.apache.org". Jakarta, of course, has taken over JEE from Oracle and made it Jakarta EE.

It is common for an Apache HTTP server to act as a "reverse proxy" to one or more Tomcat backends, which may or may not live on the same machine as Apache itself. There are many benefits to that arrangement - setting up SSL is a lot easier, Apache can use TCP ports 80 and 443 without having to run in insecure (administrator) mode, and you can use it as a single point of entry for both JEE and non-JEE webapps.

[Thomas Griffith]

To run Tomcat and Apache Server, it is separate installs and has to be configured?

[Tim Holloway]

That is correct. They are separate and unrelated products.

Typically for Unix/Linux systems, Apache is installed/upgraded using the standard OS package manager (unless someone has made an unpackaged custom build of Apache).