On December 10th, 2021, a critical vulnerability was found in Log4j. It impacts almost every organization which develops applications in Java, or that uses third-party software. Vulnerabilities get discovered every day. However, due to the impact and widespread use of log4j, this vulnerability is driving a serious discussion on the responsibilities of both maintainers and users of open source.
There are many logging libraries out there, but log4j is without a doubt the most widely used logging library developers and organizations use. When you are writing software, particularly software that communicates over the internet, if it’s receiving, sending, or processing data, one of the things you want to do is keep a record of what’s happening while your application runs. Log4j is an open source logging library that is used quite extensively for this very reason. Developers use it to ‘log’ and track everything that takes place in their software applications.
The vulnerability that was discovered in log4j is a critical 0-day vulnerability. This means the vulnerability was made public before a fix was available. This vulnerability affected almost all applications which are running particular versions of log4j, even the latest released versions (at the time). It is rated severity 10 because it gives full control to hackers who can bypass any restrictions and gain access to a computer. Once they make their way in, they can pretty much do anything including infect networks with malicious software, spy, or extract information, like private data or passwords. It is affecting individuals. It is affecting corporations. Net, it is a very easy vulnerability to exploit. Any Java application that uses this library and if they are using any previous versions that hasn’t been patched, can be hacked.
Why is everyone still talking about this vulnerability today? Why are we still seeing it in the news? Many, but by no means all companies out there, have taken steps to address the issue. Some have examined their code and if the vulnerable log4j library is present, they’ve upgraded to the latest patched version. That should do it, right? Not so fast. Some organizations may even say that they are not using the log4j library, however they shouldn’t assume that’s the case without further exploration and discovery. As a development organization, especially at the enterprise level, you participate in the software supply chain, and software code enters your development process from all over. Some code you select, and some appears from other places.
For over 15 years I have seen various ways third-party code can be brought into your organization. Since there are many entry points for open source, there are many ways you can miss log4j (see image 1.0). You get commercial software libraries from your direct (or indirect) vendors. You may very well outsource your development to contractors or partner firms who contribute to your code. Also, many software companies use open source as a foundation for their software products. That means that in addition to managing your own code, you now have to manage the licensing and the security of the code you did not write, which includes the commercial libraries and other third-party dependencies that your product relies on, as well as the dependencies of those dependencies. In the case of log4j, the library is so popular that it is quite possible companies may be using another third-party library which is using log4j, which in turn may use another third-party library that uses log4j…etc, etc. You see my point? Before you do anything, however, you must find all instances of log4j, and that is a very difficult assignment for organizations that lack expertise and the proper tools.
I run the Professional Services team at Revenera, and for many many years we have helped customers understand their code. From what I see in the work our audit services team performs, most organizations struggle with managing their third-party dependencies. Not every company out there has the right people, processes, and tools in place to identify, manage and secure their assets. A simple way for you to get started is to have a third-party review done by an audit services team. All we will need is your source/binary files and dependencies that go into your product. We can come in as an independent vendor with the right set of tools, the right people and the process that works. We don’t just do a simple scan. We analyze source code, not just the compiled binaries. We look at the build files and analyze dependencies and dependencies of dependencies. We also have the capability of performing a deeper forensic analysis on the commercial code where open source can be found. We can inspect your code and report on the findings at the most granular level.
Even if you’ve upgraded the log4j library in your own code to the latest version, you may still have vulnerable versions hiding in other third-party packages that your product depends on, and you need to determine your upgrade strategy there. You can probably fix the direct dependencies, but you can only influence the secondary ones. If you find log4j in commercial code you depend on, talk to any vendors that might be supplying you with software, and do it quickly. If you find it in an open source project, you may also need to reach out to the code owners. With both open source and commercial dependencies, you are at their mercy in terms of timetables to get a fix put in place.
The Log4j vulnerability has been known for a few months now and many organizations scrambled to fix it in December when the vulnerability was first reported. However, not all companies have fully addressed it and it is still a hot issue. Since December our team has been getting explicit requests from customers to find and identify log4j. Many of our customers unknowingly continue using the vulnerable versions of log4j and some admit that they are still downloading it and using it unintentionally. The bigger issue is that many companies were unprepared to deal with the remediation of log4j vulnerability because they did not have a complete and accurate Software Bill of Materials (SBOM) pointing them to where Log4j is located in their applications. Having one available would have helped them quickly—in a timely manner – remediate the issue when it was identified. The reality is – you don’t know what you don’t know. Our services team, with the aid of our Code Insight software, can help you find and report all places where log4j is hiding.
