The future of Log4j input in Logstash

Earlier this week, an advisory was released detailing an object deserialization security flaw in the way Apache Log4j version 2 processes input data (CVE-2017-5645). This flaw would give a remote attacker the ability to execute code of their choosing within the JVM process listening for Log4j events.

In a default Logstash install, the Log4j plugin is installed but not enabled. If you aren't explicitly using this plugin in your configuration, you are not affected by this issue.

When used in the Logstash pipeline, the Logstash log4j input plugin accepts Log4j version 1 data from remote applications. Often, any client is able to connect to Logstash because the connection offers no authentication. Given the very purpose of Logstash is to be an endpoint for receiving log data for an organization, it may not be practical to firewall the system as a form of protection. It is our expectation that Logstash will be easily reachable in most environments, and will accept whatever data is passed into it.

The currently known exploits for Java object deserialization do not work against default Logstash deployments, but the vulnerability is still present even without a known exploit. We recognize that this doesn’t necessarily mean a Logstash isn’t vulnerable to this flaw, it simply means we’re not aware of a weaponized exploit.

The Elastic Security Team does not believe the log4j input can be made 100% invulnerable  given the way it receives log data from arbitrary sources. By its very nature, object deserialization is difficult to secure and may be impossible to secure when parsing remote untrusted data. The general consensus in the security community is that if you must do object deserialization, it should only be done between systems that have a high level of trust. We do not have this level of trust with expected Logstash clients.

Remediation

We have patched the version of Log4j shipped in Logstash against this particular attack using a variant of the patch from the updated version of Apache Log4j. Updates for Logstash will be included in a future release. This will improve the security of the Log4j input, but we continue to have reservations about its security given the prior paragraph.

Existing Logstash v5.x and v2.4 users can upgrade the log4j input to receive this fix today by doing the following:

bin/logstash-plugin update logstash-input-log4j

% bin/logstash-plugin update logstash-input-log4j
Updating logstash-input-log4j
Updated logstash-input-log4j 3.0.3 to 3.0.5

Deprecation Notice

Based on the reasons stated above, we are deprecating the Log4j input. Our recommendation is for current Log4j input users to stop using log4j’s SocketAppender in their applications. For safe transport of log4j logs, users should configure log4j to write logs to disk and use Filebeat to forward to log information to Logstash. Setting up Filebeat to ship your local logs is easy and we've provided migration steps in these docs. This solution removes object deserialization from being used in an insecure manner. Additionally we have marked the Log4j plugin as deprecated and are going to remove Log4j support in Logstash 6.0.

Elastic would like to thank Marcio Almeida de Macedo of Red Team at Telstra for alerting us of this issue.