Open SourceOverview of Log4j Logging Tool

Overview of Log4j Logging Tool

Need the software equivalent of a journal to keep track of what goes wrong in online services or applications? Log4j is one such tool, allowing developers to keep track of the errors among the activities of a system and/or application. The act of tracking the activity of software and hardware processes is called “logging” and it is a useful way of keeping a watchful eye on problems that may occur. Log4j is an open-source logging library used in applications and services across the Internet. You may recognize this name from recent news coverage as well. In this article, we will go over what Log4j is, use cases for the developer tool, and the reasons it could pose a security threat in a software development environment.

What is Log4J?

When a developer is writing a piece of software that communicates over the Internet (whether it is to receive data, process data, or send data) one of the things that must be considered is how to keep track of that data via a process called logging. Logging itself is an important task, as it is the act of keeping track of the behavior of code and what happens to it, as well as what happens to data when processed by that code.

Logging helps developers understand their software better and see where data has been possibly mishandled (giving out the wrong result) or whether a hacker has attempted to gain control of the code, the data, or even could do so via malicious input.

Log4j Tutorial

Programmers can create logs in many different ways, such as outputting the system’s behavior onto a screen or writing it to a text file. But often, log files become complicated and hard to manage, as systems scale up in complexity themselves and data traffic and storage grows in size. This is where log management software like Log4j 2 comes in handy.

Apache’s Log4j is a java-based logging framework that is part of Apache’s logging services project from Apache’s Software Foundation. As of August 5th of 2015, the project committee announced the end of life for log4j 1 and since then people have used log4j 2. This successor was rewritten from scratch and was deployed with more mainstream features. Some of the features the successor has over its predecessor include support for XML, JSON, and YAML, property lookup support, and extensibility via a user-defined plug-in system. These are just some of the new features in Log4j 2, but what makes the successor a popular logging solution for many organizations, platforms, and individuals is that it is an open-source platform.

Read: Logging Microservices: Solutions and Challenges

What is Log4j Used For?

Log4j 2 is most used in web apps, cloud services, and email platforms. Google, Microsoft, Apple, Amazon, and major players use it for their cloud platforms and other products. It logs messages from software and searches for errors with a broad range for its search profile – from basic web page and browser information to the minute technical details of the system Log4j is loaded on. Not only does it create simple logs, but Log4j 2 can also generate advanced logging information by executing commands. Through this, we can say it can communicate with other sources of data, including internal directory services.

As mentioned, using a logging API is a crucial part of the software development process – particularly for online applications. It is not enough to rely solely on debugging your software yourself; in fact, you can not without the right kind of feedback. Especially in a production environment, one cannot simply rely on debugging tools alone for regular maintenance. Logging adds to the development process by sufficiently recording errors within a complicated environment, onto files or databases, with minimal human intervention. This leads to higher productivity, which cannot be achieved by manually finding errors to fix. It is within this need that Apache’s Log4j proves to be the front runner in logging for Java applications.

Log4j is the logging framework that is the most widely used on the Internet with organizations from every part of the industry integrating the library into countless applications. Nvidia, Hewlett Packard Enterprise, Cloudflare, Microsoft, iCloud, IBM, Red Hat, Salesforce, and Siemens are just some of the major platforms and organizations using Log4j as a logging solution. Even video game applications, like various versions of Minecraft, use Log4j to detect errors. Any applications and systems using Java are more than likely to use a version of Log4j. Due to its open-source nature, it is important to understand which version of the logging library you are using.

Read: The Top Java IDEs for 2022

Log4j Vulnerability Concerns

There have been reports now of what was a zero-day vulnerability in Log4j 2, publicly announced in December of 2021, involving remote code execution. The vulnerability has since been patched out in several consecutive updates, but may still be present in a number of online environments. There are ways to find this vulnerability if you believe it is within your own environment. The Cybersecurity and Infrastructure Security Agency – and several contributors – have made a scanner available for public use in order to find versions of Log4j that may be affected by this vulnerability. You can find this scanner on their GitHub. After finding the vulnerable versions, update those environments’ Log4j to the latest version.

Many organizations have now caught up to this vulnerability and have put out statements of how they plan to safeguard their – and their users’ – data. If you are using applications, services, and/or devices that you suspect are connected to Log4j 2, you are encouraged to seek out those statements and research whether there is a fix for this vulnerability. Otherwise, individual users should disable those devices/services. As is with most cases for consumers, the answer to faults in such technologies involves disabling or updating those technologies.

Sometimes with popular open-source software that have been around for a while, new features get added on top of existing code without careful consideration of what is already there. Sometimes, these new additions made by individuals trying to customize a widely available piece of software to their own needs open a previous set of code in the stack to potential attack. This was the case with Log4j 2.

Read: Best Bug Tracking Software and Tools

Among the myriad features this library has, Log4j 2 allows a developer to substitute in the strings you would tell it to log with variables. This would define other useful information for Log4j 2 to pull and show as strings, alongside the usual data. This feature behaves recursively, so when something is logged, the process will go through the data, and when it sees something akin to “${VARIABLE}”, Log4j will replace that with a string expansion of corresponding data.

If that string also contains ‘${X}’, it will repeat that process of logging. The problem here is that it will also do that with any untrusted data that it is given; for example, if it is configured to log something like the usersgent of a web browser. A crafty person could change that data to have the symbols “${}” in it so that at the time of that data being logged, Log4j would take in that expanded upon data invoked from outside the system. At the very least, this would mean you could not trust your logs, as they are partially controlled by outside users.

What makes this even worse, is another added feature that allows people to use the JNDI (Java Naming and Directory Interface) to look data up in other services – such as LDAP and DNS. Someone found that if they have made the right kind of string input for Log4j 2 to expand on, and take commands from, it could result in data exfiltration and even more malicious actions. It is, therefore, all the more important to not only test such software on the receiving end of open-source but also to work with those who maintain the software as you do decide to work with and modify their work.

Open-source is really a double-edged sword. On one hand, the advantage of open-source is that the source code is available and people can look at it and fix whatever may be wrong or add what is needed, along with a community that forms around that software. On the other hand, people could be stacking code onto more code and, instead of not letting faulty old code die, they invariably propagate faults to new features.

Open-source is not inherently secure and this will not be the last time that a security breach like this happens; chances are we have not seen how bad it can get. But with a proper community mindset around these libraries, we can remediate bugs quickly before bad actors take advantage of them and ruin the Internet for all of us.

Read: Learn the Basics of Java Logging

Latest Posts

Related Stories