1

On my server, I looked at all files containing log4j, and I only have an log4j-over-slf4j jar file.

SLF4J's page about log4shell states the following:

If you are using log4j-over-slf4j.jar in conjunction with the SLF4J API, you are safe unless the underlying implementation is log4j 2.x

However I don't find that crystal clear. How can I know whether the "underlying implementation" is log4j 2.x?

If I don't see anything on my server that contains log4j in the filename, does that mean I am fine?

Improve this question
6
  • Even if you have log4j-over-slf4j included in your project by other dependencies log4j2 can be also loaded as dependency so that you have two interfering dependencies. Which one wins in such a case may depend on the order of the dependencies or by other properties so if the log4j2 is the dominant dependency then the program may still be vulnerable depending on the version of log4j2.
    – Robert
    Commented Jan 17, 2022 at 20:26
  • Thanks for the comment. Unfortunately I feel like this is not really relevant to my question. I am well aware that the existence of log4j-over-slf4j on my system doesn't prevent log4j to be included as well. This is precisely the point of my question. I would really appreciate it if you could read my question again, especially the fact that I don't have any other file containing "log4j" in its name, and try to answer it
    – Vic Seedoubleyew
    Commented Jan 18, 2022 at 9:44
  • Your question is not described very well, especially it is not clear what you mean by "looked at all files" (what commands, also inside JAR and other archives?). Usually people searching for log4j use github.com/fox-it/log4j-finder as it also searches inside JAR files inside JAR files. This is way better than searching manually.
    – Robert
    Commented Jan 18, 2022 at 9:51
  • I have used log4j-finder, and it didn't find anything. The title of my question seems pretty clear though: Is log4j-over-slf4j vulnerable to log4shell?. From the first sentence of your answer it seems you would answer no. My question is not "what is the best way to know I am not vulnerable". I am trying to assess that particular library, and trying to make sense of SLF4J's mention of the "underlying implementation"
    – Vic Seedoubleyew
    Commented Jan 19, 2022 at 11:42
  • The answer is "No" (because it only provides the log4j API not the implementation). But it is irrelevant for your actual question: "Is my server/service vulnerable".
    – Robert
    Commented Jan 19, 2022 at 11:55

2 Answers 2

Reset to default
1

The answer is "No" because log4j-over-slf4j only provides the log4j API but does not contain any implementation of log4j.

But effectively by the presence of log4j-over-slf4j you can not derive any conclusion on the question is a the server vulnerable or not.

If you find jar files that belong to log4j-over-slf4j this gives you the hint that potentially slf4j and therefore logback is used as logging services. Logback is a different logging implementation that is totally independent of log4j.

But effectively a server can make use of multiple logging services at the same time. So to answer if a server is secure of not you have to search if somewhere in the server the vulnerable log4j code is present so you have to search for the classes that belong to log4j that causes the vulnerability.

The common way to check if an existing product contains (and therefore potentially makes use of) log4j version 1.x or 2.x is to execute the Python script log4j-finder. It searches the whole file-system for class files that are relevant for the log4j vulnerabilities and tries to match them based on their hash if they are vulnerable or not.

The big advantage of this tool is that is also searches for the class files inside JAR files even if they are nested inside inside another JAR file (and also EAR/WAR and all the other packaging formats). Such nested archives are pretty common in Java.

Of course log4j-finder is not perfect so even if it does not find anything log4j related this doesn't mean your server is free of log4j. There are other forms of packaging some times with encryption and other obfuscation technologies used that makes it very hard to detect if log4j is used or not on binary level. Therefore log4j-finder only gives you a basic level of probability that log4j is not used (or used only in a fixed version) by a program.

So in the end you should always contact the company/developer of the server and ask if or if not log4j is used and in which version.

Improve this answer
4
  • my server is a Heroku instance. According to them it is not vulnerable to log4shell unless I have dependencies that pull it
    – Vic Seedoubleyew
    Commented Jan 19, 2022 at 11:42
  • @VicSeedoubleyew Heroku is only the platform, it is good to know it is safe but then you also have to ask the developer(s) of the applications running on that platform.
    – Robert
    Commented Jan 19, 2022 at 11:51
  • That would be me :)
    – Vic Seedoubleyew
    Commented Jan 20, 2022 at 14:56
  • @VicSeedoubleyew Please check the answer.
    – Robert
    Commented Jan 24, 2022 at 16:41
1

log4j-over-slf4j only translates logging calls from LOG4J API to SLF4J API. But to really create log entries, you need a library that implements SLF4J API, for instance, Logback. In such case the application code believes the logging is done by LOG4J, but actually it is done by Logback. It looks as follows:

your code -> LOG4J API -> log4j-over-slf4j -> Logback -> file (database, Splunk, Elastic Search, ...)

To your question:

How can I know whether the "underlying implementation" is log4j 2.x?

If you developed the application you refer, then you must know how the logging is implemented in your application, and you know if particular library is used or not.

If you have not developed it, then check if the affected class is contained in the application binaries. Search for file "JndiLookup.class" in all files of your application, unpackaging all archives: .jar, .zip, .war, .ear etc. Don't be surprised if you find it not in "log4j-core-2.*.jar", but in "log4j-core.jar" or even in "<your application>.jar" (in case "fat jar" is used). If the file exists, find out its version. Then you know if you have a problem or not.

If the application uses standard libraries without repackaging them, e.g. without making a "fat jar", then the class in question is contained in log4j-core.jar or log4j-core-.jar. If you don't develop and don't know the structure, here is the source code. As you can see, class "JndiLookup.class" is contained in the module "log4j-core".

You write that the only have "log4j-over-slf4j". Thus you don't have "log4j-core" and your application is not affected by the log4shell problem.

Improve this answer
7
  • Thanks for the answer. Unfortunately I feel like I have included more details in my answer than you have accounted for. I specifically mentioned that there is no other file containing "log4j" in its name on my system.
    – Vic Seedoubleyew
    Commented Jan 18, 2022 at 9:40
  • 1
    Also, to your question Who else can know it, if not you? You do logging in your application, so you know what logging implementation you use., the fundamental reason why this log4shell vulnerability is a problem for the world, is that it's not just about the direct logging that each developer does. It's about dependencies including dependencies recursively, and some down the road that adds log4j. A very basic search about log4shell answers your reaction, that no, it is not easy to know whether there is log4j used on a particular system
    – Vic Seedoubleyew
    Commented Jan 18, 2022 at 9:42
  • @VicSeedoubleyew: If there is only log4j-over-slf4j, this means usually that there is some implementation of SLF4J. For instance, if you have a Spring Boot application and use Logback by default. But this does not guarantee that the JndiLookup.class is not present in some of your dependencies. Only if you know how the application was built, if you see in the Maven or Gradle configuration only standard dependencies and if you know that only trusted repositories were used like Maven Central, then the probability that the buggy class is present is low.
    – mentallurg
    Commented Jan 18, 2022 at 15:56
  • My question is not whether having log4j-over-slf4j guarantees that there is nothing else. My question is whether that particular library is vulnerable, and how to interpret SLF4J's mention of the "underlying implementation"
    – Vic Seedoubleyew
    Commented Jan 19, 2022 at 11:39
  • @VicSeedoubleyew: No. This library does not contain the buggy class.
    – mentallurg
    Commented Jan 19, 2022 at 13:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .