So we are excluding tons of things that the example you provided would not.
I’m not sure what bind mount is, is that something we should add to the default exclusions? Is that a filesystem type?
This is part of why we like the Logpresso scan utility, because it will not follow symlinks and it will not scan certain filesystemtypes and you can provide a custom list of exclusions.
we will stick with “locate” for linux if present and find for aix/sunos and while checking with /etc/fstab or /etc/mnttab for mounts. so that we know which mount points we are targeting. We have data stage host which has 100+ NAS mounts and binds.
this may not work unless we have more control over the mount points while looking at the /etc/fstab or etc/mnttab.
If you know for sure you have a host with tons of mounts, then that is one you might want to handle carefully, as you should. Our goal is to handle the rest of the cases seamlessly while also most likely handling this case as well as best we can.
You should run the linux fixlet/task with the run line commented out and see what our default exclusion file contains. It should handle this case already, but you would have to double check to be sure.
See here where we build a default exclusion list, plus append any custom exclusions you add yourself:
// Create Exclusions list file:
appendfile {concatenation (if windows of operating system then "%0d%0a" else "%0a") of unique values whose(it does not contain " ") of (it;"/mnt";"/dev";"/cdrom"; (unique values of (it as trimmed string) whose(it != "") of substrings separated by "%0a" of (parameter "exclusionlist" | "")) ) of items 0 of (mount points of it, filesystem types of it, types of it) whose(item 2 of it != "DRIVE_FIXED" OR item 1 of it is contained by set of ("cgroup";"cifs";"nfs";"nfs3";"nfs4";"cgroup2";"sysfs";"proc";"cpuset")) of filesystems}
If you aren’t looking at the version of the fixlet I updated in the last 30 minutes, then you aren’t seeing the newest set of code.
You can cross check the generated default exclusion list from the fixlet with which paths should be excluded, both of which you can read back remotely using a bigfix analysis property.
And you shouldn’t, so you should see what the default exclude list includes for that host.
You can test which mounts will be excluded automatically by doing:
/opt/BESClient/bin/qna
Default masthead location, using /etc/opt/BESClient/actionsite.afxm
Q: unique values whose(it does not contain " ") of (it;"/mnt";"/dev";"/cdrom"; (unique values of (it as trimmed string) whose(it != "") of substrings separated by "%0a" of (parameter "exclusionlist" | "")) ) of items 0 of (mount points of it, filesystem types of it, types of it) whose(item 2 of it != "DRIVE_FIXED" OR item 1 of it is contained by set of ("cgroup";"cifs";"nfs";"nfs3";"nfs4";"cgroup2";"sysfs";"proc";"cpuset")) of filesystems
A: /cdrom
A: /dev
A: /mnt
A: /proc
A: /sys
A: /sys/fs/cgroup/devices
T: 8233
You can put the following in an analysis property:
unique values whose(it does not contain " ") of (it;"/mnt";"/dev";"/cdrom"; (unique values of (it as trimmed string) whose(it != "") of substrings separated by "%0a" of (parameter "exclusionlist" | "")) ) of items 0 of (mount points of it, filesystem types of it, types of it) whose(item 2 of it != "DRIVE_FIXED" OR item 1 of it is contained by set of ("cgroup";"cifs";"nfs";"nfs3";"nfs4";"cgroup2";"sysfs";"proc";"cpuset")) of filesystems
I know what you are saying. your code need to work across the board. We have to pick and choose which fits best for us.
I like to have shell script to do the scan in control fashion while reading the fstab/ mnttab across unix. And do the string editing so that relevance has lesser amount of work to do.
You cannot find all the vulnerabilities this way. Logpresso scan will find the vulnerabilities within JAR files that do not have log4j in the name, as well as looking inside EAR and WER files.
Regardless, I’d love for you to check the results of the relevance I provided above and see if anything appears to be missing from the exclusion list it builds. It might handle most of what you need already and whatever it is missing is tweaks I would like to address for the sake of everyone.
What is a bind mount? is that a filesystem type? Is it something I should add to the default excludes?
How would use you use a bash command to find these vulnerable JARs? (obviously this example output is from windows, but the situation applies equally to non-windows)
[*] Found CVE-2021-44228 vulnerability in C:\Program Files\APP_EXAMPLE\bin\jdbcserver.jar, log4j 2.13.1
[*] Found CVE-2021-44228 vulnerability in C:\Program Files\APP_EXAMPLE\bin\oauthservice.jar, log4j 2.13.1
[*] Found CVE-2021-44228 vulnerability in C:\Program Files\APP_EXAMPLE\bin32\jdbcserver.jar, log4j 2.13.1
[*] Found CVE-2021-44228 vulnerability in C:\Program Files\APP_EXAMPLE\bin32\oauthservice.jar, log4j 2.13.1
So that /pf/db2client act like local FS for data stage.
but in the mount it show up like this.
mount |grep /pf/db2client
bfcdvt3nasnfs01:/vf_bpft3_datastage_04/A-DPT-IIS-PF-DB2CLIENT on /pf/db2client type nfs (rw,nodev,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=6000,retrans=2,sec=sys,mountaddr=10.83.110.34,mountvers=3,mountport=635,mountproto=udp,local_lock=none,addr=10.83.110.34)
Let me know if you see anything missing. I really really want the feedback. Thanks a ton.
Does this seem to be lacking? or does this seem sufficient? (I don’t need to know the specifics as much as I need to know if things are missing and if you can help figure out why)
Dumb question maybe but how much vetting has been done of this Logpresso company and their pre-compiled binary that folks are apparently downloading and running in their environment now?
If you’re referring to this image, as I read it that is the list of directories we would be excluding from the scan. You would have to check whether that is all of them that you need excluded. If there’s a directory that is not being excluded but you think it should, it may help to show us the content of /etc/fstab, or output of the df command. I’m not sure we can gain much by seeing the mount command itself.
This is a valid concern, as with any open source utility. You can examine the code and compile the binary yourself or instead run the JAR file directly.
I was looking into building the binaries and JAR directly through GitHub actions from the repo so they would be built clean and not by a person, so you could better trust the code in the repo → binary/jar.
GitHub actions can only be used to build native binaries for MacOS, Windows, Linux without custom hosted runners, which then gets back to the how do you trust the build if you use a custom hosted runner.
I guess the better question is, do you trust your existing detection of Log4j is complete? Can you find an alternative utility with equal reach that does not have equal concern?
I can’t say I’ve looked hard since finding this Logpresso scan utility, but it has further reach and ability to find this vulnerability than any other approach being considered, but in some ways you should consider ALL approaches.
