On December 9th 2021, a high severity vulnerability in Log4j 2 was published as CVE-2021-44228, AKA Log4Shell. Any JVM-based project using log4j-core with a version < 2.17.0 is affected. See this Cloudflare blog post for a detailed explanation, and Apache Log4j Security Vulnerabilities.
Obviously, Aerospike Database is written in C, and not vulnerable to a Log4Shell exploit. We have completed an assessment of the exposure our tools and connectors might have:
- The Aerospike REST client is a Spring Boot application, is patched with the newly released log4j-core 2.17.0. Users of this server should upgrade immediately to the latest appropriate release - 1.6.5, 1.7.2, 1.8.2, 1.9.2 and 1.10.4 . The Spring project has a December 23rd estimate for a full fix.
- The Aerospike Loader is a command-line tool, which does not run as a daemon. It has minimal potential exposure. Version 2.4.3 has been released. Aerospike Loader was removed from tools 6.2.0.
- The Java client’s logging is callback-based and does not use a logging library directly.
- Skyhook uses the Logback framework, which is not vulnerable.
- Similarly, our streaming connectors for Kafka, Pulsar, JMS, Event Stream Processing (ESP), and the XDR Proxy use Logback, which is not vulnerable.
- Our Trino (Presto) connector does not use log4j-core.
- Our Spark connector doesn’t bundle its own logger. It uses the logging mechanism of Spark. Spark users should stay tuned to information from Apache Spark and Databricks.
- The Spring Data project depends on log4j-api, but not the vulnerable log4j-core (the default logger for Spring Boot projects is not log4j 2). As soon as a fix is published, we will update the Spring dependencies of aerospike-community/spring-data-aerospike. Meanwhile, see the Spring Boot announcement mentioned above.
- ACMS does not use log4j components and all customer environments managed by Aerospike are unaffected by this CVE.
Project | Affected? | Note |
---|---|---|
REST gateway | Yes | Multiple releases with log4j-core 2.17.0 have been posted. This is a Spring Boot based, and that project has an estimate of approx. Dec 23, 2021 for the full fix. |
asloader | Yes | A command line tool, not running as a daemon, so low probability of being exploited. Has been fixed in release 2.4.3. Tools 6.2.0 removed asloader. |
Java Client | No | Does not use any logging library. |
Trino connector | No | Does not use log4j-core. |
Spark connector | No* | The connector does not bundle log4j. Users of Spark will have to pay attention to updates from Databricks / Apache Spark. |
XDR Proxy | No | Uses logback. No dependency on log4j |
Kafka Inbound connector | No | No dependency. Kafka itself may use log4j. |
Kafka Outbound connector | No | Uses logback. No dependency on log4j |
Pulsar Inbound connector | No | No dependency. Pulsar itself may use log4j. |
Pulsar Outbound connector | No | Uses logback. No dependency on log4j |
JMS Inbound connector | No | No dependency. |
JMS Outbound connector | No | Uses logback. No dependency on log4j |
ESP Outbound connector | No | Uses logback. No dependency on log4j |
Skyhook | No | Uses logback |
Spring Data Aerospike | No* | The Spring Data project depends on log4j-api, but not log4j-core. The default logger for Spring projects isn’t log4j. No action is required on our side. We’ll bump the Spring dependencies, once they’re released. |
aerospike-helper | Archived project (read-only). Stale since 2018, not used by Aerospike projects. |