Code opinion: should we trust Open Source after Log4J’s issues?


Given the vulnerability of Log4J, we need to consider how open source affects our projects, and what are the pros and cons of using such directories.

The following article is more opinion, just some random thoughts on what happened and what we can learn from this event.

Summary of the Log4J Vulnerability

To give some context to those who have never heard (or forgotten) about Log4J’s vulnerability, here’s a brief summary.

Log4J is a popular Java directory for registration. So popular that it was integrated into the Apache ecosystem.

For some reason I did not understand, the logger evaluates the log messages instead of treating them as strings. So, you can perform a type of SQL injection (but for logs): by sending a specific string format to the services that use Log4J, this string is evaluated and executed on the server; As a result, external scripts can be run on the server, allowing attackers to access your server. Of course, this is not a 100% detailed and accurate description: there are plenty of resources online if you want to dive deep into this topic.

Some evidence shows that the earliest exploitation of this vulnerability occurred on December 1, 2021, as stated by Matthew Prince, CEO of Cloudflare, In this tweet. But the vulnerability became apparent 9 days later.

The benefits of OSS projects

Log4J source code is available to the public On GitHub

it means that:

It’s free to use (yes, OSS! = Free, but it’s rare to find paid OSS projects) You can download and run the source code You can check the code and suggest changes it saves you time: you do not have to reinvent the wheel code – everything is already Done by others.

Problems with OSS projects

Given that the source code is accessible to the public, attackers can learn it to find security flaws, and of course – exploit these vulnerabilities before the community notices them.

Most of the time, OSS projects are created by individual developers to solve their specific problems. They then share these repositories to help their peers and allow other developers to work on the library. All coding is done for free and in their free time. As might be expected, quality is greatly affected by this.

What to do with OSS projects?

So what should we do with all those OSS projects? Should we stop using them?

I dont think so. Just because such types can wake up does not mean they will wake up so often.

Also, it’s pretty stupid to build everything from scratch “by chance”. Just because attackers do not know the source code, does not mean they can not find a way to access your systems.

On the other hand, we should not blindly use every library we see on GitHub. It’s not true that just because it’s open source, it’s safe to use – as the Log4J story taught us.

So what should we do?

I do not have an answer. But for sure we can take some action when working on our projects.

we need Review which external packages we use, And follow their version. Every N months, we need to write a summary (even a sufficient excel file) to update the list of packages we use. This way, if a package vulnerability is discovered and a patch is released, we can apply the patch immediately to our apps.

Finding installed dependencies for .NET projects is pretty simple: you can open the csproj File and see the list of NuGet packages you are using.

The problem with this approach is that you do not see the internal dependency: if one of the packages you use depends on another package with a known vulnerability, your application may be too vulnerable.

How can you list all your dependencies? Are there any tools that work with your programming language? Leave a comment below, it can help other developers!

Then, before choosing a project elsewhere, we must answer (at least) three questions. Does this package solve our problem? Does the code seem safe to use? Is the database active, or is it outdated?

Take some time to flip through the source code, looking for weird pieces of code. Note when evaluating the code (possible issues like with Log4J), when they make unexpected calls to external services (do they track you?), And so on.

Take a look at the history of the database: Is the database still being updated? Is it maintained by a single person, or is there a community around it?

You can find this information on GitHub on the Insight tab.

In the following image, you can see the donations to the Log4J library (available Here):

Graph of donations to the Log4J database

Does this repo have tests? Without testing (or, perhaps worse, with insignificant testing), the package should not be considered safe. Refer to the CI code and tubes, if available to the public.

Finally, hope for the future: set a standard and some procedures Rate the security of a package / repository. I do not know if this is possible, but it would be a good addition to the OSS world.

Additional readings

If you are interested in the general aspects of Log4J vulnerability, you can read this article in the Wall Street Journal:

🔗What is the vulnerability of Log4j? What to know | The Wall Street Journal

If you prefer a more technical article, DataDog’s blog has covered you. In particular, jump to the “How Log4Shell Vulnerability” section.

🔗Vulnerability Items DataDog

But if you prefer even more technical information, you can go to the official vulnerability description:

🔗Vulnerability CVE-2021-45046

Here is a JIRA card created to track:

🔗JNDI Deployment Searches (Not Message Patterns) Enabled in Log4j2 <2.16.0 | Jira


This was not the usual article / guide, it was more an opinion on the current state of OSS and what we should do to avoid problems like those caused by Log4J.

This is not the first vulnerability, and it certainly will not be the only one.

What do you think? Should we stay away from OSS?

How would you improve the OSS world?

Happy coding!





Please enter your comment!
Please enter your name here