Latest Version: Apache Pulsar Solution for Log4j Vulnerability

By Matteo Merli, StreamNative CTO, Apache Pulsar PMC Chair; Addison Higham, StreamNative Lead Engineer, Apache Pulsar Committer.

This article is translated from the StreamNative English blog, the original link: https://streamnative.io/blog/engineering/log4-mitigation-en/ more details, please refer to the StreamNative public account.

---

This article was updated on Tuesday to add details on how the latest Log4j vulnerability affects other Pulsar ecosystem tools.

Last weekend, the Apache open source project Log4j 2.16.0 was exposed to a new vulnerability, and Log4j urgently released version 2.17.0. This article provides you with an update of the latest version of Apache Pulsar regarding a critical vulnerability in Log4Shell (ie log4j). The following lists the status of the vulnerabilities in the open source version of Apache Pulsar and the actions that need to be taken to address the security holes.

Vulnerability Impact and Project Status Updates

A total of three CVEs affecting log4j have been found so far. Of the three vulnerabilities, only two affect Apache Pulsar by default. The Pulsar community has been working hard to patch the impact of all three CVEs. As of now, Pulsar versions 2.9.1 and 2.8.2 have updated the log4j version and addressed the impact of all known vulnerabilities. New release releases for Pulsar 2.7 and 2.6 are in progress. The following table summarizes the impact of log4j vulnerabilities and actions to resolve the impact of the vulnerability.

solution

Non-standard log4j/Pulsar Functions and Process Runtime User Solutions

As shown above, if the user configures the customer log4j template string or uses Pulsar Functions through the Process Runtime, even if the no message lookup workaround is configured, log4j can be exploited externally for exploits. In summary, if the user has configured log4j template strings to contain references to context objects ( $${ctx:} , %x , %mdc etc.), or using Pulsar Functions via the process runtime, your system may be at risk. We recommend that users remove custom settings and upgrade to Pulsar version 2.8.2 or 2.9.1 if they must use Pulsar Functions via process runtime.

Pulsar Functions User Solutions

Pulsar Functions written in Java need to be redeployed to get updated values. This operation is similar to using the pulsar-admin functions update command, see https://pulsar.apache.org/docs/en/functions-deploying/#updating-cluster-mode-functions an example.

Apache Pulsar open source solution

If you are using the open source version of Pulsar, see blog post . Additionally, we encourage you to upgrade to version 2.8.2 or 2.9.1 whenever possible. Additionally, users of open source or StreamNative Helm charts do not need to wait for an image update in the helm chart, and can specify a new version.

Surrounding ecology related updates

Below we list some of the tools in the Pulsar ecosystem and answer whether they are affected or not.

• Pulsar Manager - Pulsar Manager is not directly affected by the log4j vulnerability. Pulsar Manager is built using the spring framework, which uses logback for logging. Logback is also affected by the vulnerability, but unlike the log4j vulnerability, it requires permission to edit the logback configuration file directly, which greatly reduces the severity of the problem. We will release a new version of Pulsar Manager after spring releases a fixed version.
• Pulsar Spark/Flink Connector - Neither Pulsar's Apache Flink nor the Apache Spark Connector are directly affected. Neither Connector includes log4j directly, but is based on the log4j bundled in the Flink or Spark distribution you are using. Upgrading Flink or Spark will solve this problem.
• Pulsar IO Connector - The Connector in Pulsar IO (by default) does not include log4j itself, but relies on log4j provided by the Pulsar IO framework. Following the instructions above and redeploying the Connector will resolve the vulnerability. This recommendation applies to all Connectors included in Pulsar as well as those open sourced and supported by StreamNative. Self-developed Connectors may require independent verification.

Other FAQs about log4j security vulnerabilities

1. this security breach.

The underlying issue can be so severe that a Remote Code Execution (RCE) vulnerability could leave arbitrary code severely exposing a system to more damage caused by an attacker, potentially gaining full system access. No known RCE exploits against Apache Pulsar have been identified. However, we still recommend taking this issue seriously because the mechanics of executing code are complex and there are many potential possibilities. Exposing environment variables or other environmental data can be exploitable. The Apache Pulsar community strongly recommends that users take immediate action.

1. Why does the release of the open source version of

Publishing a new version of open source Pulsar involves following a well-defined process in the community. Due to other bugs discovered in the past week, the community/Pulsar PMC (Project Management Committee) decided to restart the release process several times to include the latest version of log4j to address all outstanding issues.

Other FAQs about log4j security vulnerabilities

Apache Pulsar's solution for the Log4j2 vulnerability (CVE-2021-44228)

Follow public account "Apache Pulsar" to get dry goods and news

Join the Apache Pulsar Chinese exchange group 👇🏻