log4j Vulnerability: AEM is Safe Out-of-the-Box

About the Author: Joey Smith is the Director of Client Enablement and DevOps Engineering for Hoodoo Digital. He has nearly 25 years of experience as a software engineer and systems administrator across numerous platforms. As a founder of AEMPodcast.com and AEMhq.com, he has a passion for encouraging developers to take a more active role in the long-term maintenance of the AEM platform. His experience as an AEM partner and an AEM customer has helped him become intimately familiar with many of AEM's more unique operational demands. He and his team are responsible for managing system administration and security for many of Hoodoo's customers.

Earlier this week, we posted a blog going through a high-level summary of the recent log4shell security breach. This breach has a CVSS score of 10.0, and every business and government entity that uses or may be using the log4j library should be evaluating their systems and patching them if necessary.

In this article, we won’t dive into the logistics of the vulnerabilities in log4j. Instead, we will be exploring more closely why Adobe Experience Manager (AEM), as it is out of the box, is not susceptible to the log4j vulnerability and security breach. 

Understanding log4J versus log4j-over-slf4j

Log4j is an open-source java code library widely used throughout the Java community. Security researchers recently uncovered a vulnerability in log4j that allows an attacker to run arbitrary code on almost any java service. With this vulnerability, an attacker could inject their own code to make a server running log4j do whatever they want. Alarmingly, this means that a hacker could easily create user accounts, add new system administrators, exfiltrate data, or even delete an entire database. 

While many businesses and government entities use log4j, there are several that have opted for a less complex offshoot of the log4j library called log4j-over-slf4j. This library offers most of the same features as log4j, but it has removed some of the complex and rarely used behaviors. In doing this, log4j-over-slf4j never contained the vulnerable code in its library. 

Adobe Experience Manager & the log4j vulnerability

AEM is one of the few platforms that selected to use the log4j-over-slf4j library rather than the upstream log4j library. As a result, any references to log4j in POM files or elsewhere can be resolved at runtime in AEM by the log4j-over-slf4j library. This library is an emulator which provides classes in the namespace of org.apache.log4j, but these are independent implementations of the log4j classes, not the actual classes created by log4j. 

log4j-over-slf4j provides an independent implementation of the log4j 1.x library, but no version of log4j-over-slf4j contains any of the vulnerabilities discovered in log4shell. log4j-over-slf4j is not end-of-life (EOL).

Below is an explanatory paragraph from slf4j about their emulation library. Note that using log4j-over-slf4j (which emulates log4j 1.x) is not actually the same as using the end-of-life (EOL) log4j 1.x library. slf4j is providing a much simpler set of classes that remove many of the complexities in log4j. 

Moving to log4j 2.x instead of  log4j-over-slf4j could actually increase your risk footprint, as well as interfere with several internal components of AEM itself. The statements below in bold are some important parts that indicate your inoculation to log4shell.

About log4j-over-slf4j(1):

SLF4J ship with a module called log4j-over-slf4j. It allows log4j users to migrate existing applications to SLF4J without changing a single line of code but simply by replacing the log4j.jar file with log4j-over-slf4j.jar, as described below.

How does it work?

The log4j-over-slf4j module contains replacements of most widely used log4j classes, namely:

• org.apache.log4j.Category
• org.apache.log4j.Logger
• org.apache.log4j.Priority
• org.apache.log4j.Level
• org.apache.log4j.MDC
• org.apache.log4j.BasicConfigurator 

These replacement classes redirect all work to their corresponding SLF4J classes.

To use log4j-over-slf4j in your own application, the first step is to locate and then to replace log4j.jar with log4j-over-slf4j.jar. Note that you still need an SLF4J binding and its dependencies for log4j-over-slf4j to work properly.

In most situations, replacing a jar file is all it takes in order to migrate from log4j to SLF4J.

Note that as a result of this migration, log4j configuration files will no longer be picked up. If you need to migrate your log4j.properties file to logback, the log4j translator might be of help. For configuring logback, please refer to its manual.

Below, you can see the list of log4j-related classes emulated by this log4j-over-slf4j library; you can see that neither the JMSAppender class nor the JDNIResolver class (the two classes found vulnerable to the various CVEs contained in log4shell) are emulated by slf4j.

• org/apache/log4j/RollingFileAppender.class
• org/apache/log4j/Level.class
• org/apache/log4j/Layout.class
• org/apache/log4j/Category.class
• org/apache/log4j/Log4jLoggerFactory.class
• org/apache/log4j/PropertyConfigurator.class
• org/apache/log4j/Appender.class
• org/apache/log4j/Logger.class
• org/apache/log4j/FileAppender.class
• org/apache/log4j/xml/DOMConfigurator.class
• org/apache/log4j/BasicConfigurator.class
• org/apache/log4j/helpers/LogLog.class
• org/apache/log4j/helpers/NullEnumeration.class
• org/apache/log4j/SimpleLayout.class
• org/apache/log4j/NDC.class
• org/apache/log4j/WriterAppender.class
• org/apache/log4j/ConsoleAppender.class
• org/apache/log4j/MDC.class
• org/apache/log4j/spi/HierarchyEventListener.class
• org/apache/log4j/spi/Configurator.class
• org/apache/log4j/spi/LoggerFactory.class
• org/apache/log4j/spi/LoggingEvent.class
• org/apache/log4j/spi/ErrorHandler.class
• org/apache/log4j/spi/LoggerRepository.class
• org/apache/log4j/spi/OptionHandler.class
• org/apache/log4j/spi/Filter.class
• org/apache/log4j/PatternLayout.class
• org/apache/log4j/LogManager.class
• org/apache/log4j/Priority.class
• org/apache/log4j/AppenderSkeleton.class

What to do next? 

While AEM out of the box is entirely safe from the log4shell vulnerability as indicated by the information above, there is potential that adding extensions to your AEM instance could have introduced the log4j vulnerability into your system. 

If you haven’t already, you should take steps to determine whether extensions to your system have made it vulnerable to log4shell. To determine this, you or your implementation partner should look in System Console to see if there are any bundles providing log4J other than  log4j-over-slf4j.

If there are, you should upgrade to the latest log4j version and deploy it to your servers. In addition to doing this, you should attempt to evaluate whether or not your system has been accessed. As of right now, the only way to establish this is to look for specific patterns in your log files if you are logging data. If you are not logging files, then there is likely no way to establish whether or not your system has been accessed and your data compromised. 

If you would like assistance evaluating your system logs or have questions about your AEM instance, please feel free to contact us for support. 

Sources: 

1. SLF4J Documentation: https://www.slf4j.org/legacy.html