Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.

log4j Vulnerability: AEM is Safe Out-of-the-Box | AEM Community Blog Seeding

Avatar

Administrator

BlogImage.jpg

log4j Vulnerability: AEM is Safe Out-of-the-Box by Joey Smith

Abstract

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.

Read Full Blog

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

Q&A

Please use this thread to ask the related questions.



Kautuk Sahni
0 Replies