Which Java software (listed) has the log4j vulnerability?

"You can manually check for use of affected versions of Log4J by searching your project repository for Log4J use, which is often in a pom.xml file.

Where possible, upgrade to Log4J version 2.15.0"

Hi Michel. Many thanks for your reply. The versions I listed are installed on Windows operating systems. I don't manage any "project repositories".

Is there a way to look int he Windows operating system (file system?) to tell if Log4J is being used?

As I am not a developer, I don't know what you mean by "project repository". However, it likely won't apply for me. I am asking as a general Windows admin.

Good question. I just did not want you to be left hanging. One of the best articles I have read is https://www.infoq.com/news/2021/12/log4j-zero-day-vulnerability/

but the Java versions themselves are not the issue...

Here is MS' view

https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/

Those are great articles, Michel. Thank you so much.

I will see if I find related jar files in the filesystem that are related to the jar files mentioned in the link you provided
(https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.15.0/)

I will also try to figure out if it's a simple matter of downloading the update log4j jar file and copying it into a C:\Program Files... folder, or other procedure.

You are welcome. I hope a windows JAVA developer will chime in on what is needed from a windows admin point of view.

Just blindly replacing files might break your software. You have to know what you're doing. Here's Apache's own statement:

Mitigation

Log4j 1.x mitigation: Log4j 1.x is not impacted by this vulnerability.
Log4j 2.x mitigation: Implement one of the mitigation techniques below.

• Java 8 (or later) users should upgrade to release 2.16.0.
• Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon).
• Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.

Findings the jar file will be a good start- can also take a look at this log4J detector - https://github.com/mergebase/log4j-detector. Do also note that the patch is now to 2.16

It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack. Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default. Note that previous mitigations involving configuration such as to set the system property log4j2.noFormatMsgLookup to true do NOT mitigate this specific vulnerability.

Hi Kimputer, Arun Kumar, and btan: the information is awesome. I admit Get-ChildItem is the most comfortable way to detect log4j files. I need clarity on the following, please:
1. Is the vulnerability limited to "JAR" files?
2. Is a system still vulnerable when it contains log4j*.jar files, but no Java processes are running?
3. Is looking for running Java processes a legitimate way to check if a system may be actively vulnerable?

You have to be a server to be vulnerable (and obviously serving Java apps). Just having Java installed, and running some client apps doesn't make you vulnerable.

I am so grateful for the wonderful guidance you have all provided. As a result, I am doing the following:
1. Locating log4j*.jar files.
2. Locating active/running java processes and their corresponding executable file paths.
3. Checking the vendor for any specific advice.

Yes still jar files. Note there are archive lying around too. Hence the log4j-detector would target a zip archive (e.g., *.zip, *.ear, *.war, *.aar, *.jar) where possible.

Hi btan: the log4j-detector does not work for Windows.

Hallelujah! A great many thanks, btan!

Hi Arun Kumar. This is an awesome-awesome resource. Many, many thanks!