By reading around about the Log4J vulnerability, it is not clear to me whether as a Mac/iPhone/iPad/TV user should worry, and if I should apply some temporary measure to mitigate potential problems.
From all indications so far, huge majority of Mac users should not be worried. This is almost entirely a server issue that will keep enterprise IT’s busy for awhile, but there’s almost no threat to regular computer users.
If you have installed Xcode, there are some questions about the need to update a few components, but even that’s not clear yet.
If you play Minecraft Java edition and use the server option to host Internet games, then you should definitely update that app to avoid attack https://help.minecraft.net/hc/en-us/articles/4416199399693-Security-Vulnerability-in-Minecraft-Java-Edition.
If you have installed Java and don’t still need it to support some ancient app that requires it, now would be a great time to uninstall it https://www.java.com/en/download/uninstalltool.jsp.
There have been several terminal commands proposed to scan your computer to see if you have any vulnerable versions of Log4j, but they take a long time and some have proven to be unreliable and probably unnecessary, so I have nothing to suggest to you at this time. There is also some more sophisticated software used to scan web sites to see if they have the problem, but they are even more complex and beyond the scope of most all of us (including me).
Some cross platform software is written in Java and includes its own runtime so you don’t need to install Java explicitly. This is not uncommon for scientific software, some commercial software such as papercut printer accounting, and I’ve seen some SQL front ends that do but can’t remember which they are or if they still do. But even if a Java app uses Log4j it’s unlikely that it would be easy for an outsider to attack it unless it’s a server product such as non-client papercut.
If you right-click on an app and ‘Show Package Contents’ you can poke around to see if there are any .jar files; if so, there are least some parts of the app using Java. Where in the app package they show up depends on which development environment was used. Someone with better command line ‘find’ skills than I have should be able to come up with a command to search all apps in one go.
Whether a java app uses Log4j isn’t obvious, since source code isn’t included in the apps I’ve looked at.
If still worried in spite of the small risk:
If the app doesn’t rely on network access, you can just block its net access completely with little snitch or other application based reverse firewall. If it’s an open source app, you can go to the developer’s page, download the source and search it. Commercial software developers might have a notice that you should stop using it until a fix is available or that they never used it.
An Apple engineer stated that although the just released version of Xcode does contain a couple of older versions of Log4j, they are not used in any way and therefore do not represent a vulnerability. They should be fixed in the next Xcode release.
I’ve seen at least a dozen different such find or mdfind commands that attempt to do this, but none that I am ready to pass on. Just today it was discovered that there are .jar files concealed with compressed folders that were not revealed by these scripts, so such scripts will have to be recursive and able to expand any archives.
Ooh, finally Java has a bad enough reputation that even Java devs don’t want anyone to know that they haven’t yet kicked the habit…
Is it just me, or does Java get a lot of bad rep for stuff that has strictly speaking nothing to do with Jave per se? Is it perhaps so that often when people use Java that works well they aren’t even aware it’s Java, but when they suffer trouble it’s immediately “arrrrghh, damned Java again!”
Java developers I’ve known or interacted with have tended to believe that it’s truly “write once, run everywhere, no problem”. But of course that’s always a fairy tale. Especially when you end up with 6 different versions of the runtime on a machine, and each Java app is using a different configuration method to try (and often fail) to find the runtime version that actually works. I’ve had to spend too much time untangling snarls. Crashplan used to be Java, and there was a 3rd party utility that not only forced CP to find the correct runtime, but forced it use more memory so it wouldn’t silently stop backing up largish file systems. But that was a delightful aberration.
Multiple versions are less of a problem now that embedding the proper runtime in the app has become common, but the oddities of user experience still exist. Not just in java though–any ‘write once’ cross platform environment is always going to be nicer for developers than for users. But even that’s less obvious on the Mac now that Apple sabotages it’s own interface guidelines right and left. Such as Music on Catalina showing scroll bars that are totally non-functional.
[Vax Fortran was the inverse of write once run everywhere. It was one compiler, run any dialect of fortran correctly–IIF you set the compiler flags correctly. Man, I miss Vax, and teaching smug post docs that yes you do have to take into account that some flavors of fortran test a loop at the top, and some test at the bottom, and yes, that does make a difference to the results…]