Third CVE
https://nvd.nist.gov/vuln/detail/CVE-2021-4104
This one affects Log4j 1.x in specific non-default configurations. We are aware of this. Current guidance is to upgrade to 2.16.0, I’m not expecting workarounds in the end-of-life 1.x versions.
Jason, Was the entry for 2.16 added as a match that means you are on the latest version whereas the all 2.15 entries and below mean - vulnerable?
Yes that’s right.
Also 2.12.2 is also considered “fixed”, where 2.12.2 supports JRE 7 while 2.16.0 requires JRE 8 or higher. Both are accounted for in the Analysis.
Thanks for the clarification. One other thing we noticed was a “not matched” verdict for 2.15 as follows:
C:\Program Files\Code42\lib\log4j-core-2.15.0.jar, 419a8512895971b7b4f4f33e620d361254e5c9552b904b0474b09ddd4a6a220b, Not Matched
It’s because the hash doesn’t match the one in the property (make sense). So I am wondering is there more than one version 2.15 out there or should we consider all other ones not matching ‘bad’?
We have quite a lot of “not matched” from libraries that at are binary-bundled with vendor apps.
Not sure if this was previously mentioned but the BFI 10.0.7 has the remediation for CVE-2021-44228: BigFix Inventory has a remediation for Log4j Vulnerability CVE 2021-44228
In addition for detecting the Log4j vulnerability in other products the BFI development team has created a separate post for custom template signatures:
The logpresso scan utility does seem to find vulnerable versions bundled into other JAR files, but it won’t find those that have been compiled into a binary like an EXE but that is very very hard to detect.
@jgstew ran the logpresso task on a few windows and linux machines as a test. On the analyses side for windows I am seeing a few error results in the analysis:
The expression could not be evaluated: File error "classFileIOError" on "C:\Program Files(x86)\BigFix Enterprise\Bes CLient\BPS-Scans\results-log4j2-scan.txt": "Windows Error 0x20%: The process cannot access the file because it is being used by another.
When I go to the system I can see the file exists.
Wondering if others are seeing this too?
That probably indicates the scan was still running and had the file locked when the analysis was evaluated.
For a quick workaround, right-click those computers and “Send Refresh” to have them re-evaluate, or wait for the next evaluation period.
We should be able to new a new version of the Analysis out tomorrow to use ‘locked lines’ rather than ‘lines’ of file.
Thanks for clarification on that. I am seeing results now from my Linux systems with some unbelievable elapsed times. Which seems to be more a product of the scanner itself vs the bigfix content. But is it really that quick? Here is the output from 2 linux systems one with affected files the other without.
Server 1:
File reads:
Logpresso CVE-2021-44228 Vulnerability Scanner 1.7.0 (2021-12-17)
Scanning directory: / (without /cdrom, /dev, /mnt, /proc, /sys, /sys/fs/cgroup/blkio, /sys/fs/cgroup/cpu,cpuacct, /sys/fs/cgroup/cpuset, /sys/fs/cgroup/devices, /sys/fs/cgroup/freezer, /sys/fs/cgroup/memory, /sys/fs/cgroup/net_cls,net_prio, /sys/fs/cgroup/perf_event, /sys/fs/cgroup/pids, /sys/fs/cgroup/rdma, /sys/fs/cgroup/systemd, /sys/fs/cgroup/unified, /dev, /run, /dev/shm, /run/lock, /sys/fs/cgroup)
Scanned 21397 directories and 175881 files
Found 0 vulnerable files
Found 0 potentially vulnerable files
Found 0 mitigated files
Completed in 1.26 seconds
Property Result = <none>
Server 2:
File Reads:
Logpresso CVE-2021-44228 Vulnerability Scanner 1.7.0 (2021-12-17)
Scanning directory: / (without /cdrom, /dev, /mnt, /proc, /sys, /sys/fs/cgroup/blkio, /sys/fs/cgroup/cpu,cpuacct, /sys/fs/cgroup/cpuset, /sys/fs/cgroup/devices, /sys/fs/cgroup/freezer, /sys/fs/cgroup/memory, /sys/fs/cgroup/net_cls,net_prio, /sys/fs/cgroup/perf_event, /sys/fs/cgroup/pids, /sys/fs/cgroup/rdma, /sys/fs/cgroup/systemd, /sys/fs/cgroup/unified, /dev, /run, /dev/shm, /run/lock, /sys/fs/cgroup)
[] Found CVE-2021-44228 vulnerability in /usr/share/elasticsearch/lib/log4j-core-2.11.1.jar, log4j 2.11.1
[] Found CVE-2021-44228 vulnerability in /usr/share/elasticsearch/bin/elasticsearch-sql-cli-7.9.1.jar, log4j 2.11.1
Scanned 7691 directories and 83105 files
Found 2 vulnerable files
Found 0 potentially vulnerable files
Found 0 mitigated files
Completed in 0.62 seconds
Property Result=
/usr/share/elasticsearch/lib/log4j-core-2.11.1.jar, log4j 2.11.1
/usr/share/elasticsearch/bin/elasticsearch-sql-cli-7.9.1.jar, log4j 2.11.1Tested the scan on AIX and it doesn’t show any applicable machines on it. Any suggestions to modify so that a scan can be run?
//CVE-2021-44228 - Log4j2 - Vulnerable files
unique values of (it as trimmed string) of preceding texts of firsts "," of following texts of firsts "vulnerability in " of (if exists property "locked lines" then locked lines of it else lines of it) whose (it as lowercase does not contain " (mitigated)" as lowercase) of files "results-log4j2-scan.txt" of folders "BPS-Scans" of parent folders of parent folders of client folders of sites "actionsite"
//CVE-2021-44228 - Log4j2 - Mitigated files
unique values of (it as trimmed string) of preceding texts of firsts "," of following texts of firsts "vulnerability in " of (if exists property "locked lines" then locked lines of it else lines of it) whose (it as lowercase contains " (mitigated)" as lowercase) of files "results-log4j2-scan.txt" of folders "BPS-Scans" of parent folders of parent folders of client folders of sites "actionsite"I’m working my way to get the Java version for all OS. There is a lot of OS not covered by the precompiled options.
The jar should work on any os and architecture
Whoops, I forgot to use the newer locked lines inspector! My bad!
I have seen some very fast scan times on my NVMe systems, but 1.26 seconds does seem a bit fast for that many files.
Example:
Logpresso CVE-2021-44228 Vulnerability Scanner 1.6.3 (2021-12-16)
Scanning directory: /
Scanned 3462 directories and 35526 files
Found 0 vulnerable files
Found 0 potentially vulnerable files
Found 0 mitigated files
Completed in 3.15 seconds
This seems less surprising to me given the number of files being scanned on NVMe, but your result seems somewhat plausible.
I’m still working on a solution for non x64 based systems to run the JAR directly instead of using the Linux or Windows binary which will only work on Intel/AMD x64 systems currently.
yep, that is what I should be doing, good call. You want to file a pull request against my analysis in GitHub?
I’m planning on doing this today. What do you have so far?
FYI, there have been 4 releases of the log4jscan utility in the last 19 hours, including this important addition:
Support Log4j 1.x CVE-2021-4104 vulnerability scanning using --scan-log4j1 option.
So now it supports detection of the CVE within the EOL Log4j 1.x versions. I’ll look to add this to the default command shortly.
Also this:
Redefined exit code
-1 failed to run
0 for clean (No vulnerability)
1 for found
2 for some errors
Use --old-exit-code for legacy automation.
I’ll be updating the scan tasks to use this newer version soon, as well as incorporating a method for custom path exclusions.
Soooooooo, I am actually not that far into non Windows as I would have liked today…
However, I started the all Java approach on Windows and I am very happy with it thus far.
Its not tested on anything apart from Windows 2012R2 and Windows 2016, however the reason why I mention this is because it will be largely re-usable with the NIX stuff, with just some commands slightly different, unzip vs tar etc and how its run of course, but the base structure is set up.
If you would like to have a look, here it is attached to this post. I am not opposed to using the compiled versions for x64 linux/windows but for now it was easier for testing for me to start on windows with java, can change that to use precompiled versions easily later.
Log4j logpresso scanner WIP 006.1.bes (15.3 KB)
Its almost midnight here and I am wasted from this week. If you think this is usable to port to other OS, which I believe should be doable, please let me know. I plan to continue it when I can but again, if you feel it is suitable as a foundation to cross over to linux flavours, and feel like it, go for it heh.
Please note:
If you think its worth a laugh, then please do so 
Also, my plan is to use JRE from https://adoptium.net/releases.html?variant=openjdk11&jvmVariant=hotspot for anything that can
Temurin 11 JRE compressed archives only for anything non SunOS, Temurin 8 for SunOS, JRE for all due to being small, around 40MB
Same.
You don’t need to do this because you can put the JRE in the client utility cache and then it would not be redownloaded even if you don’t leave it behind. Any solution I end up cobbling together will not leave JRE behind and will not give the option to leave it behind. Leave nothing behind that is a future problem.
You will see the client utility cache is being used for the existing Windows scan task for the Unzip.exe file. I recommend setting all clients to have a client utility cache that is at least 200mb, 500mb preferred. The default is a useless 10mb.
Any small utility prefetch that is shared across multiple fixlets/tasks should be placed into the Utility Cache. You must use the utility actionscript command referencing the exact file that was prefetched.
// Add Unzip to Utility Cache:
utility __Download\unzip.exe
_BESClient_Download_UtilitiesCacheLimitMB to 500I just finished automating this.
My fixlets/tasks are being automatically generated using templates that automatically get the newest logpresso utility prefetches inserted.
In my testing JRE 11 is the maximum. I think JRE 7 is the minimum but I have not tested this.
Ah yes, it did occur to me but for some reason I have not tested how it deals with updates, I should have tested it. This will ahve to keep running possibly forever into the future (updates, inadvertent old installs, you name it).
So it needs to deal with JRE updates. I don’t mind keeping this way as an option (till i get some proper sleep to think about it), but the utility is probably the most correct method.
Ah yes, that is very nice indeed! There is a great many updates, which is excellent.
Suspected this may be the case but definitely not enough testing on my end yet
From: Release 2.1.0 Release · logpresso/CVE-2021-44228-Scanner · GitHub
“From now on, JDK7 is the minimum supported version.”
For my first pass at this, I planned to actually have a task that is only relevant on machines that already have a JAVA binary in the PATH env var and reference the first JAVA found in PATH. This will not work if that JAVA is not > 7 and < 11 so that is not the best solution. Actually downloading a portable JRE to run it is more likely to work consistently.
This is precisely the reason I went with this method instead of hunting java around the system.
My original thought was similar to yours tho, to see if its in the path, then to do a file based search for java, then finally to check the version of it.
However… this is madness perhaps… a lot of problems potentially. Even if the path once found is stored in a variable for reuse, would need re-testing it is still there, still version is correct, still scavenger hunt to find other versions if its not there, then end up at the download portion anyways after all that.
The download of a non installable java version just struck me as less problematic, problematic from perhaps a change management perspective but this problem will have priority clearance at all times I guess.
Not to mention the java would have to be downloaded anyways even in the scavenger hunt version if its not on a system at all, so not much better from change perspective.