Every now and again we hear a news story about a digital threat. Some of these threats, for example the infamous millennium bug, sound like funny conspiracy theories. Others are so big that it’s hard to wrap your mind around them, as was the case with Edward Snowden’s revelations on global surveillance in 2013. Still others get catchy names and convince many to replace their hardware, like Spectre and Meltdown did in 2018. Whatever their type, the flaws appear with striking regularity. Unfortunately, as 2021 drew to a close, we got yet another one.

The latest entry in the long list of spectacular safety risks concerns Java, the programming language of our choice. So let’s take this opportunity and learn more about it.

Have we been naughty?

Apparently, we in the IT industry got a lump of coal for Christmas. On December 9, a huge vulnerability in the Apache Log4J logging library was discovered. Dubbed Log4Shell, it allowed attackers to inject malicious code by manipulating user-controlled data, for example logins or email headers.

Say that again?

As ridiculous as that sounds, you did read that right. Let’s break it down piece by piece.

The Apache Log4J library is a logging tool, meaning it keeps a record of what a Java application is doing and writes that record to a file. Later, programmers can go to that file and see a timeline of what was happening, for instance to discover why the app malfunctioned or crashed.

When a user types in their login or password, when they write a subject header or do anything similar, Log4J logs that for future reference. But there’s a catch: if the logged string is a command, it gets executed in the app with full privileges due to a fault in the library’s design.

Hackers could and most likely did take advantage of that fault to extract sensitive information or even take control over entire apps. There’s evidence that ransomware groups had been trying to leverage the flaw months before it made the news.

What are the stakes?

Sounds bad? It’s even worse if you consider a few key facts. One, the attack was easy to perform with even intermediate technical skills. All it took was typing some widely available commands into a >field in the browser. Two, we can not be certain of how long the flaw had been known and exploited before being announced and fixed. And finally, what we do know is that approximately 90% of enterprise software relies on the Log4J library, and therefore has been susceptible to the attacks.

The good news is that there is a fix by now and that you can determine whether the flaw has been exploited in your software by examining the log files.

How does all of that affect Clurgo and me?

Clurgo abandoned the Log4J logging library well over a few years ago. In all our projects since then, we’ve been using an alternative library called Logback. You can decide for yourself whether that was wisdom or luck, but if your organization still uses the library, the best option is to update it to the latest version and audit the logs for proof of breach.

What’s the lesson?

The Log4J logging library is open-source. Some argue that open-source projects are more reliable than proprietary ones because everyone can inspect and fix the code. But that’s only theory. In practice, stories such as this warn us that open-source should be approached with caution. The fact that everyone can doesn’t mean that anybody will. Especially without proper remuneration and quality assurance, since open-source projects are often developed by volunteering enthusiasts rather than by fairly compensated professionals with reputations to keep.

At any rate, Log4Shell reminds us that before using it, we should analyze open-source software for potential flaws instead of taking it at face value.