Thread by @aaspnas

Reading about detecting #log4j vuln on the Java platform, which is a highly complex undertaking. Libraries can be found as an extracted archive, .jar archive, .war archive containing .jar files, .ear archive containing .war and .jar files, all depending on the platform (1/11)

Then there is Spring Boot with .jar files containing other .jar files. Long ago you could even have your .jar files in a .zip archive. Guess you can look for these on your file system recursively. With a special class loader Java could load classes from anything... (2/11)

Normally the specific jar file would be named something like log4j-core-{version}.jar, but if the developer decided to re-package log4j with the application the jar file name can be anything. (3/11)

In the jar file (or directory) you would expect to find the path org/apache/logging/log4j/core/lookup/ and especially the file JndiLookup.class but what if a developer also decided to refactor the package structure? Technically i guess then it would not be a #log4j vuln? (4/11)

Developers also back up their packages on servers, so vulnerable instances will be found as backup versions not in use. Guess no one will patch the backup copies... There is hence likely to be lots of false positives. (5/11)

But is #log4j in use? For that you need to see the classpath of the executing java process. This can be set as environment variables, shell initiation scripts or in a script read at startup, or on the command line. The classpath consists of directories and archive files. (6/11)

Tomcat on Windows apparently also uses values stored in the Registry... The process list anyway gives you a list of running Java processes. If the process is only executed at a given time (daily/weekly/monthly) it is even more difficult. (7/11)

In addition to that you have Graal VM Native images which I don't even have a clue how to recognise... Even systems where you do not have Java can be affected. For your own code i guess you can at least be certain if you use #log4j but else... not so much... (8/11)

Then you have build automation and deployment pipelines to take into account. Manual pathing of a vulnerable server may be overwritten with an old version automatically somewhere in the future if the #log4j package version is statically assigned. (9/11)

Detecting by testing (over the net) is also not easy. With a Java process responding to traffic on a given port you can still have many applications responding to different paths, all consisting of their own set of classes. Knowing what is being logged is also hard. (10/11)

So: Lots of things that can go wrong, and room for misunderstanding / confusion. I guess there are things that we even don't know at this time and have misunderstood. Feel free to comment if you find the reasoning here wrong or missing something crucial! (11/11)