Log4j CVE-2021-44228 Detection and Mitigation

Content Authoring
86

parameter “FilePattern”=“log4j-core*.jar” this one already in the action script right.Can you please help me

87

parameter “FilePattern”=“log4j-core*.jar” ,can I use parameter “FilePattern”=“log4j *.jar”

88

Sure, feel free to customize to your needs.
If you find additional modules that are impacted, that are found in your filter but not in the original, please do let me know!

89

if I customized the file pattern with log4j,I think analysys also need to modfiy right?

90

I am being challenged with potentially adding to the Windows System environment variables setting:

LOG4J_FORMAT_MSG_NO_LOOKUPS=true

Has anyone done this, or have a relevance to check for its existence on a windows system?

Any feed back on successfully mitigating the vulnerability, considering the potential other things that could make this ineffective?

Thank you

1 Like
91

We are looking into this right now.

There are actually 3 different environment variables that you would need to merge this option into in order to be certain to disable it as far as I can tell.

This seems to be the safest and easiest option to globally disable this vulnerability.

"JDK_JAVA_OPTIONS";"_JAVA_OPTIONS";"JAVA_TOOL_OPTIONS"

You can read these env vars with an analysis property like follows: ( I haven’t fully tested this relevance yet, but it should be universal for client 8.1.535.0+ )

values of (variables ("JDK_JAVA_OPTIONS";"_JAVA_OPTIONS";"JAVA_TOOL_OPTIONS") of it; (if (windows of operating system) then (x64 variables ("JDK_JAVA_OPTIONS";"_JAVA_OPTIONS";"JAVA_TOOL_OPTIONS") of it) else NOTHINGS) ) of environments

That said, you actually need to handle each variable as a separate case, and you need to “append” the new option into it while keeping all the existing ones, but also remove any existing LOG4J_FORMAT_MSG_NO_LOOKUPS configurations if there is one that is actually setting it to false for some reason.

You might actually want 3 separate fixlets/tasks to handle all 3 env vars independently.

I don’t currently have example systems with results for this relevance, so it is hard for me to know what a complicated existing env var setting might look like.

It would be easiest to create a fixlet/task that would set this setting if these env vars do not yet exist, but harder to do if they do already have values within them that should be preserved.

Related:

2 Likes
92

No, the Analysis will still report the results - except I specifically exclude three extraneous hits from my filter (-javadoc.jar ; -javatest.jar; -source.jar)

1 Like
93

Thanks Jason.

I will try if required

94

I am also looking at content for that (on Windows).
Can you confirm the value you’re expecting to add, maybe include a source? The guidance I’m seeing refers to setting

-Dlog4j.formatMsgNoLookups=true
in the “JAVA_TOOL_OPTIONS” variable, and possibly also in _JAVA_OPTIONS and JDK_JAVA_OPTIONS as @jgstew notes

1 Like
95

I was looking at this too and took the reference from MS

Workarounds
To help mitigate the risk of this vulnerability until the more complete security update can be applied, customers should consider the following mitigations steps. A service restart will be required for these changes to take effect. These workarounds should not be considered a complete solution to resolve this vulnerability:

In case the Log4j 2 vulnerable component cannot be updated, Log4J 2 versions 2.10 to 2.14.1 support the parameter log4j2.formatMsgNoLookups to be set to ‘true’, to disable the vulnerable feature. Ensure this parameter is configured in the startup scripts of the Java Virtual Machine:
-Dlog4j2.formatMsgNoLookups=true.
Alternatively, customers using Log4j 2.10 to 2.14.1 may set the LOG4J_FORMAT_MSG_NO_LOOKUPS=”true” environment variable to force this change.
Kubernetes administrators may use “kubectl set env” to set the LOG4J_FORMAT_MSG_NO_LOOKUPS=”true” environment variable to apply the mitigation across Kubernetes clusters where the Java applications are running Log4j 2.10 to 2.14.1, effectively reflecting on all pods and containers automatically.
For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

2 Likes
96

I update Bigfix Compliance and VM Manger Tool but the version is 2.13.3. Should it not be 2.15.0?

97

Interesting, this seems like a cleaner option to use. Can much more easily tell if it is exists or not and if it is set to true or not.

I can handle the actionscript to set this on windows, but for everything else, especially UNIX, how do you set the env vars on the command line or file?

Having to use a file instead of a command is kind of a pain in some cases if the env var already exists.

I wonder if the env var must be set to exactly "true" or if it is case insensitive?

This would be TRUE on any system that needs this env var, and I am assuming it is case sensitive for now:

not exists unique values whose(it contains "true") of values of (variables ("LOG4J_FORMAT_MSG_NO_LOOKUPS") of it; (if (windows of operating system) then (x64 variables ("LOG4J_FORMAT_MSG_NO_LOOKUPS") of it) else NOTHINGS) ) of environments

I would say this action will require a restart for 2 reasons. One is that the bigfix client won’t update the results of env vars until restart of the agent I believe, but also, you must restart any services that launch JVMs for this setting to get picked up, and there might be an unknown number of services that would be affected, so it is hard to restart only the services that need it.

I haven’t tested this, but this is what I came up with for actionscript:

// Note, this currently only handles windows, but could be expanded to handle other cases.
continue if {windows of operating system}


if {windows of operating system}
waithidden CMD /C setx LOG4J_FORMAT_MSG_NO_LOOKUPS true /m

if {x64 of operating system}
action uses wow64 redirection False
waithidden CMD /C setx LOG4J_FORMAT_MSG_NO_LOOKUPS true /m
endif

action requires restart

endif

// TODO: add actionscript to set env vars on non-windows:

The idea is to remove the continue if later once non-windows use cases are handled, as well as move the action requires restart to after the endif

This will be relevant on ALL systems, even those without apparent Java installed, but that is intended.

Seems like this command didn’t work for me:

CMD /C set LOG4J_FORMAT_MSG_NO_LOOKUPS="true"

and this one doesn’t keep the quotes?

CMD /C setx LOG4J_FORMAT_MSG_NO_LOOKUPS "true" /m

Is setx available on most windows OSes? Not sure how far back it goes.

Looking closer to the referenced MS doc, seems like the quotes are not needed.

Fixlet to apply this mitigation on windows here: bigfix-content/fixlet/set LOG4J_FORMAT_MSG_NO_LOOKUPS env var to TRUE - Universal - CVE-2021-44228 mitigation.bes at main · jgstew/bigfix-content · GitHub

98

Preserving quotes is a weirdness between CMD and SETX. This should work but it’s not at all clear to me that the value should have the literal doublequotes in it.

waithidden cmd.exe /c "setx /M LOG4J_FORMAT_MSG_NO_LOOKUPS """true""""

1 Like
99

yeah, it seems it should NOT have the literal quotes in it now that I look closer.

100

If I recall correctly, setx goes at least as far back as XP/2003. Prior to that, I think it was an add-on from the Resource Kit tools.

1 Like
101

This seems to be working for me on Win10 and Win11:

Not 100% sure how to test that it is getting picked up properly by java / log4j

102

Here is a fixlet that implements the detection of this mitigation on all platforms, but implements the workaround on all windows platforms here:

This needs actionscript added to set the env var on non-windows platforms. If anyone could provide examples, that would be helpful.

Seems like this would be the mitigation for MacOS: (untested)

if {mac of operating system}

if {not exists lines containing "LOG4J_FORMAT_MSG_NO_LOOKUPS" of files "/etc/profile"}
wait /bin/sh -c '/bin/echo "export LOG4J_FORMAT_MSG_NO_LOOKUPS=true" >> /etc/profile'
endif

endif

Seems like this should work for Linux: (untested)

if { unix of operating system }
if { exists folders "/etc/profile.d" AND not exists lines containing "LOG4J_FORMAT_MSG_NO_LOOKUPS" of files "/etc/profile.d/CVE-2021-44228.sh" }

wait /bin/sh -c 'echo -e "export LOG4J_FORMAT_MSG_NO_LOOKUPS=true" > /etc/profile.d/CVE-2021-44228.sh'

endif
endif

Not sure if AIX, HP-UX, Solaris, or others are special cases.

103

Similarly on Windows I’ve published https://bigfix.me/fixlet/details/26898
This one sets every environment variable I’ve seen referenced on Windows -

  • JAVA_TOOL_OPTIONS = -Dlog4j.formatMsgNoLookups=true (preserving any existing entries)
  • JDK_JAVA_OPTIONS = -Dlog4j.formatMsgNoLookups=true (preserving any existing entries)
  • _JAVA_OPTIONS = -Dlog4j.formatMsgNoLookups=true (preserving any existing entries)
  • LOG4J_FORMAT_MSG_NO_LOOKUPS = true (overwriting any existing entry)

Again, I’m not at all confident in how effective this will actually be, as it depends on the startup scripts for whatever Java application to not clobber these values, and requires Log4j to be at one of the versions (2.11.0 - 2.14.0 I believe) that respects these values. But it may be useful in reducing attack surfaces while you wait for other applications to update or give their own workaround guidance.

1 Like
104

Jason, I noticed the primary scans are for v2.x. Since v1.x is eol, my management is asking for that also (as they do not fully trust our Infosec scan results)
Can the 1.x hashes be included?
The scan as it is is running great btw. Good job to everyone who has worked on it.

1 Like
105

Log4j 1.x versions have a different naming convention…I’m not sure what it is, and I don’t have a known hash list.

You could certainly update your copy of the scan task to widen the file filter, and then those results should show up in the Analysis, just with “No Match” on the hash values. Usually the version number might be apparent from the filename.

Just to reiterate though, it’s not just a matter of “1.x EoL and not evaluated”…for this particular thing, 1.x did not even provide the JNDI lookup function that’s being exploited, as far as I’ve read.

1 Like