Log4j Vulnerability Underscores a Negative Side Effect of Open Source

I am not going to talk about the Log4j vulnerability and how to determine if you are impacted and how to recover. I am sure there are plenty of articles on that. In my view, the more important discussion is had by taking a hard look at the open source software model and considering the possibility that this is what happens when source code is public.

Log4J Vulnerability

However, I will pause and review at a very high level what the Log4j vulnerability is/was. I say was because it has been fixed from Apache, but that doesn’t necessarily mean the fix got updated into any given piece of software. If you have a piece of java-based software, the best starting point is to inquire with the vendor.

The vulnerability was a situation that could lead to remote code execution. For those not aware, a remote code execution vulnerability means that someone can remotely, as in over the Internet, run code on your computer — or your company’s servers. It’s basically the worse kind of vulnerability.

In the case of Log4j, if one could force a certain series of characters to be processed by the application and sent to the logging framework through log4j, it would execute the code. Here is the CVE:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228

Unfortunately, most web apps that have a “login” feature, will log the username which one uses to attempt to log in. So, the exploit would simply be to use that special sequence of characters as the username.

There is a little more to it, but there are widely available scripts which automate the whole process and the end result is the attacker has a terminal shell on the target system and can then do whatever they please on the remote system.

As I said before, it’s basically the worst kind of vulnerability.

How Does One Randomly Discover The Programming Errors that Lead to Vulnerabilities?

I doubt very seriously that someone just happened to stumble upon this issue with Log4j, but instead, they looked at the source code for this JNDI feature set and from there they saw where it was designed/implemented with a security issue at bay.

The Nature of Open Source Software Provides Anyone the Ability to Dig Through Source Code and Detect Security Weaknesses

It’s called a code review when a developer’s peer scrutinizes the developer’s code looking for potential problems. There is nothing stopping anyone in the world from performing a “code review” to scrub code for security mistakes. But, the proper code review ends with the developers remedying the weakness. Obviously, in the case of attackers combing through source code, their end goal is not to communicate back to the developer but instead develop an exploit.

I’m not sure there is any way of preventing this, and I certainly am not suggesting the “open” nature of Open Source Software is extinguished.

But I do think that open-source development teams will need to spend a lot more cycles doing their own security code reviews. Even better, would be to ensure the development teams place security as a high priority throughout the entire development lifecycle, including the design.

Just a quick plug for Carlisle Technology Solutions: We do put security as the highest priority throughout the development lifecycle. None of our software projects were vulnerable to this Log4J vulnerability.