/home/bamboo/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-core/2.16.0/ca12fb3902ecfcba1e1357ebfc55407acec30ede/log4j-core-2.16.0.jar
This is the path.
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.
Got it, thanks.
The relevance is actually matching on the “files-2.1” and retrieving version “2.1”. Should have an update in an hour or so.
Thank you Jason. I will test it again after your update.
some thing like this, this will look for “.jar”
((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
Please see the disclaimer on our Community Content efforts in detecting and mitigating these Log4j vulnerabilities at Log4j Vulnerability Identification and 3rd Party Remediation Solution Testing Statement
3 Likes
Do you mean BigFix Inventory?
yah one of those package. which does OS metadata.
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
Hi guys! First of all we are all so grateful for the hard work that you are doing to help us novices keep our customers happy! A co-worker told me to day he heard people talking about how lucky we were to decided to opt for Bigfix a few years back when a decision was being made on which endpoint management software should be used at our corporation and I agree!
Last Monday we decided that we’d go for the removal of the jndilookup.class way in situations where we couldn’t update the software since most of our customers use 3rd party software containing the log4j library. We started testing out the Logpresso-based fixlet as soon as @jgstew published it on Github with great results before slowly and cautiously expanding out. We have been scanning all servers and workstations in our environment and our customers as well and have in many cases deployed the fixlet with the --force-fix switch with no reports of applications starting to misbehave…yet 
Next up are those macOS machines. I’ve been spending some time tonight trying to deploy just the logpresso jar file provided on git with no results at all… I’ve tried both modifying the Linux-Logpresso fixlet as well as simply deploying a shell script with one line.
Do you guys know if there is a trick to invoke a java -jar command on a macOS, is it not possible or is my insomnia causing all of this? 
2 Likes
Do you have java on your Mac?
Yes I have. Our thought was deploying Java the latest Jave to our clients before running the java -jar logpresso.jar file and that way being able to scan the Macs… Do you know happen to know of any other way to do this on Macs ?
My recommendation is not not deploy java.
It is a nightmare.
You want portability so it’s gone forever at the end of the scans.
Unless you intend to maintain and update it constantly once installed this is not the right way forward.
1 Like
No we were actually intending to just remove Java from the Macs in a few days, weeks until the storm settles. Is it possible to use the Logpresso without Java on Macs ?
I’m working on porting to Linux the work I already did on windows to run in java using openjdk jre compressed archives.
However it is not done yet, like almost everyone, been a tough week
2 Likes
Oh ok that’s awesome, can’t wait!
Been a long week indeed, can’t wait to get some good night sleep!
That is amazing!
I would suggest trying to get it to work in terminal manually on a mac and get that refined before trying to do it with bigfix. We are headed down this path but haven’t got there yet.
This is what @JasonWalker and I hope to be doing soon, but if people have examples for various platforms that would help us a ton, especially how to invoke portable java on various obscure non-windows platforms.
Yeah I forgot to mention that… I have already tried running those commands with out any issues on the mac but when ever I deploy it it just won’t work… I started thinking if this was something like when running stuff under System context on Windows or if it’s something with java… Also tried running this as root and it work fine
Strange stuff
What is the exact command that works fine on Mac manually? I can help adapt it to bigfix content.
What did you try in an action that didn’t work?
In generally, I would recommend something in the format of:
/bin/sh -c "cd folder && command > output.txt"
MBP:/ james$ /bin/sh -c "cd /tmp && echo testing123 > test.txt"
MBP:/ james$ cat /tmp/test.txt
testing123
I ran this from / not from /tmp yet it still runs within /tmp due to it starting with cd /tmp && which is a tip I picked up originally from @it_cat long ago.
2 Likes
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
2 Likes