Unfortunately, due to the nature of the vulnerability, this problem will not ever blow over as long as java is in existence. The possibility of people inadvertently installing or updating or restoring from backup is immense. This could bring you back to square one and you would pay a heavy price if it’s simply ignored.
I recommend scan tasks to run forever into the future and change processes changed to include a section about Log4j going into the future, as part of any change that involves touching software.
Log4j is just ingrained into so many applications that most people are not even aware of its existence. It’s impossible to know it even exists unless scans were run in most cases.
There is no logpresso solution without java at this stage for Mac.
The pre compiled versions are very limited in terms of OS support but the java should work with a great many OS versions.
This is what I guess the community here is trying to accomplish now
Probably only needs to be like once a week or something like that in the future, but you are right, you have to double check and make sure things don’t pop back up. That said, if they do, it might be because the fix broke the app, so you have to be careful if you are refixing and rebreaking the same app over and over.
Hey thanks. This really helped out. I was definitely not using /bin/sh -c ! But so I had issues with it outputting it to results.txt… did some digging around and finally got it to work like this:
That command looks good. For some reason I don’t understand the outer quotes have to be double quotes for commands run with bigfix even though bash works either way.
It won’t redirect to a file without invoking it with a shell generally. A lot of things you take for granted are actually provided by the shell, not the OS, but it is hard to tell which is which when You are already starting in the shell in the terminal.
Another example is finding an executable on the PATH. That is usually done by the shell.
When you run installler or msiexec without the shell, it works but is actually more efficient in terms of processes, threads, and memory. This is why bigfix doesn’t always invoke using a shell every time.
Have you encountered this problem? We are going to need to deploy a JRE and the scanner JAR file to support other operating systems, and I’d like to check whether using the JAR instead of the prebuilt binary avoids the problem.
I am seeing this problem with a mass scan we are running this weekend. Many servers were not able to execute the scan due to the missing libs/dependencies. I don’t have exact numbers as of now, hope to run a report during the week.
(This reply is specifically to @fermt, or anyone else who can reproduce the “Missing VCRUNTIME140.dll” issue; or we can adapt similar for anyone on Linux encountering a glibc version error)
If you’re willing to run a test on any of these machines, it would be very helpful to know the results. I hope we can workaround this by downloading a portable JRE, and using the JAR version of the scanner. But there’s the possibility that just pushes off the VCRUNTIME dependency to the JRE.
There’s now a another CVE against Log4j 2.x, prompting upgrade to Log4j2-core-2.17.0.jar. This is the third CVE against Log4j2, and the fourth against Log4j in total this week (including the 1.x versions that are not expected to be fixed)
The “File Scan Count” and “Scan Duration” are useful in identifying failed scans or scans that may have included network paths - a scan with 0 files or empty result probably failed to execute, and a scan with a long duration may have crossed network paths or scanned very large filesystems.
The “Scan Technology” entry includes the Logpresso-Log4jscan version that was executed.
The “File result details” entry contains the full line from the logfile, including the version of Log4j-core that the Logpresso scanner recognized, if any.
Thanks for doing this Jason. I was putting it off since the scan part was in flux.
This is actually expected and listed as a dependency for the Logpresso scan utility binary for windows. We should adjust the relevance to check for this dependency for the windows binary scan task. I had not actually come across any systems that did not already have this installed in my testing on my workstations, but it makes sense that servers with very few programs installed would be more likely to be missing it.
We have confirmed this dependency does NOT exist if you run the scan using a JRE and the JAR file version of the Logpresso scan utility.
Yep, this is a bugger and why I made the java version for windows.
I actually got enough info to start on linuxnversion but not the time yet. Maybe at night time here…
Thanks to Jason, we now have a working version that runs using a pre-installed JRE/JDK and runs the JAR. This will also get around the dependency problem on windows, but with the dependency of having a JRE/JDK already installed somewhere we can find with relevance.
This should resolve @fermt 's issue if the relevance does find java already installed somewhere.
We are still planning on a fixlet/task with the capability to run the JAR version of the utility by downloading a portable JRE/JDK, running the utility, then cleaning up after so the portable JRE is not left behind in a way that can be used. The main issue with this approach is it is going to require figuring out the right JRE to download for every platform and testing it. This will be nearly impossible to do without community help for platforms that we do not have test machines available for.
@fermt, I was able to reproduce this on some of my Win2019 servers. I verified that using an existing JRE on the machine to run the JAR-based scan works, so the Universal JAR scan may work better for you – if you have Java installed on the machine already.
I’ll be working today on versions that download a portable JRE to run the JAR scans on systems without JREs. I’m going to be starting with Windows and Linux, intending to follow-up with Mac, AIX, etc. after.
