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).
6 Likes
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.
1 Like
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âŚ]