Is the MariaDB JDBC driver affected by the Log4j vulnerability?
Is the MariaDB Java connector affected by the security vulnerability recently discovered in Log4? By default, the Java connector does not use Log4j. However, if you have configured it to use SLF4j, keep reading.
For information beyond the scope of the MariaDB JDBC driver, read Log4Shell and MariaDB.
Note: This blog was updated 2021-12-15 to include detail regarding CVE-2021-45046.
The Log4j vulnerability
Apache Log4j is a popular open-source logging framework for Java applications. It’s used in a variety of open-source and enterprise projects including cloud vendors and email service providers. On December 9, 2021, a 0-day vulnerability was found in Log4j that could result in remote code execution, allowing a hacker to execute arbitrary code in a system. The vulnerability is known as “Log4Shell” and is tracked as CVE-2021-44228.
In short, the vulnerability allows an attacker to inject a JNDI lookup string that invokes, for example, a remote LDAP server (controlled by the attacker) which in turn returns a malicious Java class:
If a string like this is logged by Log4j, a malicious Java class can run arbitrary code (via a static block of code, for example).
Fortunately, only Log4j versions 2.x before 2.15.0 are affected. See the Apache Log4j security vulnerabilities page for more information. The vulnerability is not present in Log4j versions 1.x.
How to mitigate CVE-2021-44228
The best strategy to mitigate the vulnerability is to update the Log4j dependency in your projects. Version 2.16.0, which removes message lookups, is already available. Props to the team for quickly releasing this.
Update: Log4j 2.16.0 also fixes the second vulnerability tracked as CVE-2021-45046.
The MariaDB JDBC driver doesn’t use Log4j 2.x. However, it supports SLF4J. Check whether or not you are using the Log4j binder for SLF4J, and if so, upgrade Log4j accordingly or set the following configuration variable:
Or set the following environment variable:
Note: Logging is only enabled when explicitly set by the
log parameter. Besides Log4j, you can also opt for other SLF4J bindings like Jakarta Commons Logging, Logback, or the Java Logging API.
If you are using Maven, you can run the following command to find out if your project depends on Log4j:
mvn dependency:tree -Dincludes=org.apache.logging.log4j:log4j-core
Here’s an example of the kind of output you’ll get in a vulnerable project:
If for some reason your project doesn’t compile you can alternatively run:
Search for the
log4j-core dependency and check the version used.
List of links in the blog: