Is there any workaround available for Log4j Vulnerability on Windows 10.

I can see BigFix has released the workarounds for BigFix products like (SCA and BFI). need to know is there any workaround for all affected windows machines

See the discussion here: Log4j CVE-2021-44228 Detection and Mitigation

See the ongoing summary here: Log4j CVE-2021-44228, CVE-2021-45046 Summary Page

We have a fixlet/task to scan for affected JAR files for all operating systems including windows and an analysis to collect the results.
See here:

We have a mitigation for windows for the RCE CVE using environment variables.
See here: https://bigfix.me/fixlet/details/26898 (requires reboot after running)

The fixlet/task I created to address the RCE CVE through Env Vars for non-windows platforms has some gaps because it is not setting the env var in a way that affects system services currently, so that would need solved.

The env var options do not mitigate the newer denial of service CVE in Log4J.

We are working on fixlets/tasks to use utilities to scan for all affected JARs and offer mitigations. This will fix the newer denial of service CVE in Log4J.

Thanks, this helps.

Is there a complete solution only for windows?

In some ways the most complete solution is to do many thing, not just one thing.

There is the scan for JARs and analysis for reporting (for windows and non-windows)

There is setting the env var to prevent the RCE CVE.

There is replacing JAR files with the newest version to mitigate both CVEs but with potential application problems, but reverting it should just be a matter of swapping back the saved version of the JAR with the replaced one.

There is running a utility like the Logpresso utility that can remove the effected class from existing JAR files, but also unknown JAR files that are using it but under a different name, as well as JAR files embedded within WAR and EAR files.

Technically you might need to do all 3 of these things to be fully mitigated everywhere, yet the env var one is least likely to impact the applications, while the other 2 are the only ways to fully mitigate both CVEs but with a higher likelihood of impacting the application, though it does seem like this is the path that others are going down with positive results.

We have content for scanning and reporting on JAR files that are affected.

We have content for setting the env vars on windows.

We have experimental content for replacing the JAR files on windows.

We are working on extending these solutions to *nix, but the env var option is a bit trickier on *nix and needs to handle some additional use cases.

Looks for these solutions here: Log4j CVE-2021-44228, CVE-2021-45046 Summary Page

and the full discussion and solutions here: Log4j CVE-2021-44228 Detection and Mitigation - #140 by jgstew

1 Like

I have just added a fixlet that includes the ability to run the Logpresso utility to detect exposure for windows: https://github.com/jgstew/bigfix-content/blob/master/fixlet/Logpresso%20log4j2-scan%20-%20Windows%20x64.bes

I need to work on doing the same for Linux as well as an analysis to read the results.

Looks like Jar files need to be replaced with latest version of log4j and probably, I have many application which is using the log4j vulnerable machines and need to resolve. What would be the best way to replace JAR file.

And

Also, Logpresso Utility need to be also executed with other two mitigation which should resolve the issue completely, is there any information on how to execute, as i am pretty new to log4j.

to fully mitigate there are 2 options, either replace the JAR files with newest OR use the logpresso utility to fix the existing ones even if they are the older version. You don’t technically need to do both, but I am finding the logpresso scan utility finding more results than other methods.

You can run this to get logpresso results on windows x64 devices now: https://github.com/jgstew/bigfix-content/blob/master/fixlet/Logpresso%20log4j2-scan%20-%20Windows%20x64.bes

Thanks for all your work!

I have created the Task and analysis related to logpresso and can find vulnerable CVE paths log paths. I can even see the multiple paths affected and initiated environment variable mitigation. As the result can be seen from logpresso generated logs. what are the next steps to follow or to be tested to resolve the issue?