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.