I think query is excluding the NAS /bind mounts.
1 Like
Do you mean we arenāt excluding something and we should be?
I mean XFS is not part of the query. We are good.
1 Like
Ah got it! I was confused.
Jason, you worked with Brad last night regarding the regex to pull the version. I work with him.
1 Like
Thanks for the response. Iām not a java developer so was just curious if someone has analyzed this to be reasonably sure itās safe. I looked up the company and their website is in Korean so that gave me pause to say the least, so tought Iād ask if folks using this have given it any consideration.
1 Like
I have given it some, yes, but it is worthy of some further investigation. I would love to spend the time automating the builds of the binaries / JAR using GitHub actions, but instead I have been looking into running the JAR directly to make the solution more complete, but maybe I should shift focus and let someone else pick up the running the JAR work.
Iām investigating the build automation here: automate build of JAR and binaries using GitHub Actions Ā· Issue #133 Ā· logpresso/CVE-2021-44228-Scanner Ā· GitHub
Some discussion here:
- https://www.reddit.com/r/sysadmin/comments/rfoz5d/logpresso_cve202144228scanner_log4j_vulnerability/
Some info about the company here:
I have actually been filing issues on github with the project and the developer has been SUPER responsive.
I havenāt touched Java since school, but I could look it over.
I was also looking into adding some automated code validation and scanning to the github project, but I got kind of confused if it was giving me results or not, or where they would show up for the CodeQL analysis I was doing.
1 Like
I still havenāt looked at this example, but I have created a work in progress stub fixlet/task for running the JAR here:
@jgstew Do you know if the logpresso scan and fix remediated vulnerability for all versions of log4j? The reason I ask is because according to CISA website it says that removing JndiLookup.class is only for versions 2.0-beta9 to 2.7 as in the screenshot below.
That info is outdated and for the older remote code exploit CVE. If you follow that it would close the remote code exploit CVE but it wouldnāt close the newer CVEs filed against log4j unless you remove the JndiLookup.class for all versions. This is what the fix is the newer Log4j does.
Basically removing the JndiLookup.class closes all of the current CVEs for all of the versions, it is just that there are other options for other version for other CVEs.
If you only care about closing the remote code exploit CVE on windows, then applying this fixlet/task and rebooting SHOULD be sufficient, but we donāt know for certain: https://bigfix.me/fixlet/details/26898
It sets the env vars that should close that CVE, but there are more CVEs since then.
1 Like
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.
https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45046
3 Likes
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.
1 Like
Probably another dumb question - when you say all versions you mean 2.x only? or is it looking for it in 1.x also?
The Logpresso scan utility is looking for 1.x also.
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.
Everyone, Iāve made some major changes on the Summary page at Log4j CVE-2021-44228, CVE-2021-45046 Summary Page
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.
2 Likes
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ā)
Thank you.
Can you give me the full filename, or better yet the full pathname, of the file that is flagging?
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.
1 Like