log4j remediation (beyond jamf server)

Valued Contributor II

I'm kinda late to the log4j party.


How would we address this on the individual machines?  Is it a 1 by 1 touch of the affected devices and manually deleting and replacing the files? Is there a script that can run a find/replace with newer patched versions?  



Valued Contributor

I think it depends on what it is.  I've just packaged a patch for SPSS which had the files buried in the App.

Probably best to figure which machines have log4j and where and start from there

Valued Contributor

I assume that many products that use log4j are not necessarily vulnerable in the same way as servers that listen on http or https. So for now I don't worry about clients that have apps that use log4j. I also would not go and replace files individually, since I don't know which version they are using and which version they are compatible with. I hope the vendors will look after their product and maintain its security, and if they don't off it goes.

Esteemed Contributor II

Might want to reach out to each vendor to get their mitigation statement. They're either going to say "we fixed it in XYZ version" and you can deploy the update, or they might say "our product is not vulnerable", or might blow it off.

Pays to be proactive, download/deploy/run this log4j detector tool to get ahead of the curve.


PS, I submitted an "Issue" asking for the ability to exclude paths, the developer turned it around the next day.


And advice or tips on how to even deploy this for folks not familiar with things like this?

New Contributor II

looking for the best way to deploy this using Jamf to our endpoints as well.  

Esteemed Contributor II

Deploy the log4j-detector-latest.jar to the folder you deploy your scripts/tools to, for example:


"/Library/Application Support/COMPANYNAME/log4j-detector/log4j-detector-latest.jar"

Run a script Once Per Computer that scans the computer, and spits out a file with vulnerability info (paths to log4j instances, including the assessment that is in the end of each line) into the same folder. Note use of nohup and & so the policy doesn't hold up any pending policies, and don't bother updating inventory, that'll happen later, when the file is populated.

The reason for Once Per Computer, is to avoid a race condition that can return empty or missing reports. If you want to run it again, flush all logs for the policy.


if [ -e "/Library/Application Support/COMPANYNAME/log4j-detector/log4j-detector-latest.jar" ]
/usr/bin/nohup /usr/bin/java -jar "/Library/Application Support/COMPANYNAME/log4j-detector/log4j-detector-latest.jar" / > /Library/Application Support/COMPANYNAME/log4j-detector/log4j-detector.txt"

Have an Extension Attribute (EA) that grabs the contents of the file.

SUMMARY_FILE="/Library/Application Support/COMPANYNAME/log4j-detector/log4j-detector.txt"

if [ -e "$SUMMARY_FILE" ]
echo "<result>$(/bin/cat "$SUMMARY_FILE")</result>"
echo "<result>DoesNotExist</result>"

If you want to get slick, create another Extension Attribute that gives you a count of all instances of for example "_VULNERABLE_":


HOW_MANY=$(/usr/bin/grep -o "_VULNERABLE_" "/Library/Application Support/COMPANYNAME/log4j-detector/log4j-detector.txt" | /usr/bin/wc -l | /usr/bin/awk '{print $NF}' 2>/dev/null)

echo "<result>${HOW_MANY}</result>"

Hope this is helpful.


Contributor III

And if you were told the log4j exists or is being detected and running the detections says otherwise?

Has anyone run up against this?

How woudl one upgrade after detection is successful?

Much apprecitated help.