I believe the recommendation has changed and they no longer think the env var closes the original cve:
The reason these measures are insufficient is that, in addition to the Thread Context attack vector mentioned above, there are still code paths in Log4j where message lookups could occur: known examples are applications that use Logger.printf(“%s”, userInput), or applications that use a custom message factory, where the resulting messages do not implement StringBuilderFormattable. There may be other attack vectors.
Oh, like it doesn’t even fully close the original remote code execution CVE anymore? I don’t know if I heard that detail fully. Kind of from @JasonWalker
It is one of those things, setting the env vars won’t hurt more than removing the affected class, it just won’t fully mitigate. I see the env var as something you can roll out everywhere with the least impact to applications and the easiest to roll back. It just doesn’t go far enough. You can’t stop there and call it done. That said, if the env var fix does break an application, then going further most likely will as well, so in a completeness sense, it might make the most sense to do all of the above using the env var option to see if anything breaks before moving forward and further.
Hi Jason,
I have just started bigfix. I had run the task and created analyses for our servers. The relevance “CVE-2021-44228 - Log4j potentially vulnerable pathnames”, does it find the log4j-core versions including 2.15.0?
My code was like this
"it whose (not exists (following texts of last “log4j-core” of it) whose (it as version >= version “2.15.0”)) of (it as string) of (if exists property “locked lines” then locked lines of it else lines of it)"
and now i changed it to the latest one - https://bigfix.me/analysis/details/2998668. But I’m not seeing the results for the servers having log4j-core version 2.13.3 but for 2.10.0
When it is >=2.16.0, does it only look for versions greater than 2.16.0? Could you please help.
The official BigFix content for Inventory is moved to the top, followed by the experimental things we’re doing with Logpresso / Log4jscan now.
The earlier detections using shell scripts is deprecated at this point. There are limitations to how good it is at detecting log4j-core, especially if it has been renamed or embedded in other JAR, WAR, or EAR files; as well as limitations on excluding network paths from being scanned.
Can you verify you are using the latest version? There have been many updates. While the link you posted is the latest, the relevance on that property should have already been updated -
it whose (not exists (first matches (regex("[[:digit:]]{1,3}(\.[[:digit:]]{1,3}){1,3}")) of it) whose (it as version >= version "2.16.0" or it as version = version "2.12.2")) of (it as string) of (if exists property "locked lines" then locked lines of it else lines of it) whose (it does not start with "SCAN_COMPLETE" and it as lowercase does not end with "-javadoc.jar" and it as lowercase does not end with "-sources.jar" and it as lowercase does not end with "-tests.jar") of files "BPS-Scans/CVE-2021-44228.txt" of folder(pathname of parent folder of parent folder of client folder of site "actionsite")
Yes, I’m using the latest version. But it shows the log4j-core-2.16.0.jar as vulnerable as well.
Should i modify the relevance to look for versions <=2.16.0?
it whose (not exists (first matches (regex("[[:digit:]]{1,3}(.[[:digit:]]{1,3}){1,3}")) of it) whose (it as version >= version “2.16.0” or it as version = version “2.12.2”)) of (it as string) of (if exists property “locked lines” then locked lines of it else lines of it) whose (it does not start with “SCAN_COMPLETE” and it as lowercase does not end with “-javadoc.jar” and it as lowercase does not end with “-sources.jar” and it as lowercase does not end with “-tests.jar”) of files “BPS-Scans/CVE-2021-44228.txt” of folder(pathname of parent folder of parent folder of client folder of site “actionsite”)
I just want heads up where we burn our hands while scanning the VM’s.
If VM data store ( OS image data file) coming from the same NAS share then NAS header will get IO spike. if all the VM’s sharing the same NAS header for data store.
If we have bigfix insight which collects OS metadata that would be much easier to know where the jar or any other file is present. we have told security that we would like to install that bigifix insight package across the nodes. let see how it goes.
((substrings separated by “” of substrings separated by “.jar” of it ) of first matches (regex(“[[:digit:]]{1,3}(.[[:digit:]]{1,3}){1,3}.jar”))
OR
Q: it whose (it >= “2.16.0”) of ((substrings separated by “” of substrings separated by “.jar” of it ) of first matches (regex(“[[:digit:]]{1,3}(.[[:digit:]]{1,3}){1,3}.jar”)) of “/files-2.1/log4j-core-2.16.0.jar”)
A: 2.16.0
Likewise, had the same idea for custom text box(es) but one step at a time. I’ll try port my windows version hopefully sometime today. After sleeping on it, still seems like good option and should be relatively little work