Log4j-core 2.8.2: Fix Critical Vulnerabilities Now!
Hey everyone! Today, we're diving deep into a critical topic: the vulnerabilities found in log4j-core-2.8.2.jar. This version of the Apache Log4j library has some serious security flaws that you need to be aware of, especially if you're using it in your projects. Let's break down what these vulnerabilities are, how they can impact your applications, and most importantly, how to fix them.
📂 Vulnerable Library - log4j-core-2.8.2.jar
The Apache Log4j Implementation
Library home page: https://www.apache.org/
Path to dependency file: /target/classes/META-INF/maven/org.whitesource/log4j-netty-sample/pom.xml
This library, residing at the specified path, is flagged with multiple vulnerabilities that could pose significant risks. Understanding the specifics of each vulnerability is crucial for effective remediation.
Here's a quick rundown of the vulnerabilities we'll be discussing:
| Finding | Severity | 🎯 CVSS | Exploit Maturity | EPSS | Library | Type | Fixed in | Remediation Available |
|---|---|---|---|---|---|---|---|---|
| CVE-2021-44228 | 🟣 Critical | 10.0 | High | 94.5% | log4j-core-2.8.2.jar | Direct | 2.12.2 | ✅ |
| CVE-2021-45046 | 🟣 Critical | 9.0 | High | 94.3% | log4j-core-2.8.2.jar | Direct | 2.12.2 | ✅ |
| CVE-2021-44832 | 🟠 Medium | 6.6 | High | 50.4% | log4j-core-2.8.2.jar | Direct | 2.12.4 | ✅ |
| CVE-2021-45105 | 🟠 Medium | 5.9 | High | 66.7% | log4j-core-2.8.2.jar | Direct | 2.12.3 | ✅ |
| CVE-2020-9488 | 🟡 Low | 3.7 | Not Defined | < 1% | log4j-core-2.8.2.jar | Direct | ch.qos.reload4j:reload4j:1.2.18.3 | ✅ |
Let's dive into each of these vulnerabilities in detail. Understanding the specifics is key to mitigating the risks effectively. We'll cover what each vulnerability does, its potential impact, and, of course, how to fix it.
🟣CVE-2021-44228
Vulnerable Library - log4j-core-2.8.2.jar
The Apache Log4j Implementation
Library home page: https://www.apache.org/
Path to dependency file: /target/classes/META-INF/maven/org.whitesource/log4j-netty-sample/pom.xml
Dependency Hierarchy:
- ❌ log4j-core-2.8.2.jar (Vulnerable Library)
Vulnerability Details
CVE-2021-44228, also known as Log4Shell, is a critical remote code execution (RCE) vulnerability. Specifically, Apache Log4j2 versions 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) are affected. The vulnerability stems from JNDI (Java Naming and Directory Interface) features used in configuration, log messages, and parameters. These do not properly protect against attacker-controlled LDAP and other JNDI-related endpoints.
An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. This is a huge deal because it means an attacker could potentially take over your entire system just by crafting a malicious log message. Imagine someone injecting a simple string into a log that then allows them to run any code they want on your server. Scary, right?
From log4j 2.15.0, this behavior has been disabled by default, which is a good start. However, to completely eliminate the risk, upgrading to version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1) is essential, as this functionality has been entirely removed. It's crucial to note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.
Publish Date: Dec 10, 2021 12:00 AM
URL: CVE-2021-44228
Threat Assessment
Exploit Maturity: High
EPSS: 94.5%
Score: 10.0
Suggested Fix
Type: Upgrade version
Origin: https://logging.apache.org/log4j/2.x/security.html
Release Date: Dec 10, 2021 12:00 AM
Fix Resolution: 2.12.2
🟣CVE-2021-45046
Vulnerable Library - log4j-core-2.8.2.jar
The Apache Log4j Implementation
Library home page: https://www.apache.org/
Path to dependency file: /target/classes/META-INF/maven/org.whitesource/log4j-netty-sample/pom.xml
Dependency Hierarchy:
- ❌ log4j-core-2.8.2.jar (Vulnerable Library)
Vulnerability Details
CVE-2021-45046 is another critical vulnerability that arose because the initial fix for CVE-2021-44228 (Log4Shell) in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This means that even if you thought you were safe by upgrading to 2.15.0, you might still be vulnerable if you had specific configurations in place.
Specifically, this vulnerability allows attackers with control over Thread Context Map (MDC) input data to craft malicious input data. This is possible when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (e.g., ${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC). By using a JNDI Lookup pattern, attackers could trigger an information leak and remote code execution in some environments, and local code execution in all environments. This is a severe escalation of the original Log4Shell vulnerability.
To fully address this, Log4j 2.16.0 (Java 8) and 2.12.2 (Java 7) remove support for message lookup patterns and disable JNDI functionality by default. It's super important to upgrade to these versions to ensure your systems are fully protected. Don't just assume the first fix was enough; double-check and upgrade again!
Publish Date: Dec 14, 2021 04:55 PM
URL: CVE-2021-45046
Threat Assessment
Exploit Maturity: High
EPSS: 94.3%
Score: 9.0
Suggested Fix
Type: Upgrade version
Origin: https://logging.apache.org/log4j/2.x/security.html
Release Date: Dec 14, 2021 04:55 PM
Fix Resolution: 2.12.2
🟠CVE-2021-44832
Vulnerable Library - log4j-core-2.8.2.jar
The Apache Log4j Implementation
Library home page: https://www.apache.org/
Path to dependency file: /target/classes/META-INF/maven/org.whitesource/log4j-netty-sample/pom.xml
Dependency Hierarchy:
- ❌ log4j-core-2.8.2.jar (Vulnerable Library)
Vulnerability Details
CVE-2021-44832 is a medium severity remote code execution (RCE) vulnerability affecting Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4). This vulnerability can be exploited when a configuration uses a JDBC Appender with a JNDI LDAP data source URI, and an attacker has control of the target LDAP server.
In simpler terms, if you're using Log4j to log data to a database via JDBC, and your configuration allows specifying a JNDI LDAP data source, an attacker who controls the LDAP server can execute arbitrary code on your system. This is because Log4j will attempt to retrieve data from the attacker's LDAP server, potentially leading to malicious code execution.
The fix involves limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2. By restricting the protocol to java, Log4j prevents the use of LDAP and other potentially dangerous protocols, thus mitigating the RCE risk. If you're using JDBC Appenders with JNDI, it’s crucial to upgrade to one of these versions.
Publish Date: Dec 28, 2021 07:35 PM
URL: CVE-2021-44832
Threat Assessment
Exploit Maturity: High
EPSS: 50.4%
Score: 6.6
Suggested Fix
Type: Upgrade version
Origin: https://logging.apache.org/log4j/2.x/security.html
Release Date: Dec 28, 2021 07:35 PM
Fix Resolution: 2.12.4
🟠CVE-2021-45105
Vulnerable Library - log4j-core-2.8.2.jar
The Apache Log4j Implementation
Library home page: https://www.apache.org/
Path to dependency file: /target/classes/META-INF/maven/org.whitesource/log4j-netty-sample/pom.xml
Dependency Hierarchy:
- ❌ log4j-core-2.8.2.jar (Vulnerable Library)
Vulnerability Details
CVE-2021-45105 is a medium severity denial-of-service (DoS) vulnerability affecting Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3 and 2.3.1). This vulnerability occurs because Log4j2 did not protect from uncontrolled recursion from self-referential lookups.
An attacker with control over Thread Context Map data can cause a denial of service by crafting a string that, when interpreted, leads to infinite recursion. Imagine a log message that references itself, causing Log4j to loop endlessly, consuming resources until the system crashes. This is particularly concerning because it only requires control over the log data, not the application code itself.
The issue was fixed in Log4j 2.17.0, 2.12.3, and 2.3.1. These versions implement protections against self-referential lookups, preventing the infinite recursion and mitigating the DoS risk. If you're using a version of Log4j in the vulnerable range, upgrading to one of these fixed versions is essential to prevent potential denial-of-service attacks.
Publish Date: Dec 18, 2021 11:55 AM
URL: CVE-2021-45105
Threat Assessment
Exploit Maturity: High
EPSS: 66.7%
Score: 5.9
Suggested Fix
Type: Upgrade version
Origin: https://logging.apache.org/log4j/2.x/security.html
Release Date: Dec 18, 2021 11:55 AM
Fix Resolution: 2.12.3
🟡CVE-2020-9488
Vulnerable Library - log4j-core-2.8.2.jar
The Apache Log4j Implementation
Library home page: https://www.apache.org/
Path to dependency file: /target/classes/META-INF/maven/org.whitesource/log4j-netty-sample/pom.xml
Dependency Hierarchy:
- ❌ log4j-core-2.8.2.jar (Vulnerable Library)
Vulnerability Details
CVE-2020-9488 is a low severity vulnerability involving improper validation of certificates with host mismatch in the Apache Log4j SMTP appender. This means that if you're using Log4j to send log messages via email using SMTPS, the application might not properly verify the SSL/TLS certificate of the mail server.
This could allow a man-in-the-middle (MITM) attack to intercept the SMTPS connection, potentially leaking any log messages sent through that appender. An attacker could eavesdrop on sensitive information being transmitted in your logs, such as passwords, API keys, or other confidential data. While the severity is lower, the potential for information leakage makes it a risk worth addressing.
The vulnerability is fixed in Apache Log4j 2.12.3 and 2.13.1. These versions implement proper certificate validation, ensuring that the SMTPS connection is secure and preventing MITM attacks. If you're using the SMTP appender with SMTPS, it's advisable to upgrade to one of these versions to protect your log data.
Publish Date: Apr 27, 2020 03:36 PM
URL: CVE-2020-9488
Threat Assessment
Exploit Maturity: Not Defined
EPSS: < 1%
Score: 3.7
Suggested Fix
Type: Upgrade version
Origin: https://reload4j.qos.ch/
Release Date: Apr 27, 2020 03:36 PM
Fix Resolution: ch.qos.reload4j:reload4j:1.2.18.3
Stay safe out there, and keep your dependencies updated! Addressing these vulnerabilities promptly is key to maintaining a secure application.