CVE-2021-44228 Alternative Mitigation

Elastic Stack Logstash
1

Is it possible to drop the new log4j-core-2.15.0.jar for logstash as an alternative mitigation for the 5.x logstash version? The recommended mitigation step to remove the JndiLookup.class would not be desirable for deployments as our scanners will still flag it as non-compliant. Is there any configuration files that requires updating?

Is it possible to simply replace these references found below?

grep -rnw /opt/elastic -e 'log4j.*2\.6'
/opt/elastic/logstash-5.6.16/logstash-core/lib/logstash-core_jars.rb:6:  require 'org/apache/logging/log4j/log4j-core/2.6.2/log4j-core-2.6.2.jar'
/opt/elastic/logstash-5.6.16/logstash-core/lib/logstash-core_jars.rb:14:  require 'org/apache/logging/log4j/log4j-api/2.6.2/log4j-api-2.6.2.jar'
/opt/elastic/logstash-5.6.16/logstash-core/lib/logstash-core_jars.rb:15:  require 'org/apache/logging/log4j/log4j-slf4j-impl/2.6.2/log4j-slf4j-impl-2.6.2.jar'
/opt/elastic/logstash-5.6.16/logstash-core/lib/logstash-core_jars.rb:23:  require_jar 'org.apache.logging.log4j', 'log4j-core', '2.6.2'
/opt/elastic/logstash-5.6.16/logstash-core/lib/logstash-core_jars.rb:31:  require_jar 'org.apache.logging.log4j', 'log4j-api', '2.6.2'
/opt/elastic/logstash-5.6.16/logstash-core/lib/logstash-core_jars.rb:32:  require_jar 'org.apache.logging.log4j', 'log4j-slf4j-impl', '2.6.2'
/opt/elastic/logstash-5.6.16/logstash-core/gemspec_jars.rb:5:gem.requirements << "jar org.apache.logging.log4j:log4j-slf4j-impl, 2.6.2"
/opt/elastic/logstash-5.6.16/logstash-core/gemspec_jars.rb:6:gem.requirements << "jar org.apache.logging.log4j:log4j-api, 2.6.2"
/opt/elastic/logstash-5.6.16/logstash-core/gemspec_jars.rb:7:gem.requirements << "jar org.apache.logging.log4j:log4j-core, 2.6.2"
/opt/elastic/logstash-5.6.16/vendor/bundle/jruby/1.9/gems/logstash-input-beats-3.1.32-java/lib/logstash-input-beats_jars.rb:11:require_jar('org.apache.logging.log4j', 'log4j-api', '2.6.2')
2

In addition to replacing those references, you would also need to replace the vendored log4j jars themselves, and you would be somewhat on your own with a custom hand-rolled mitigation. Bear in mind that Elastic-released artifacts go through somewhat extensive testing and validation, in this case not only for base functionality but also explicit validation for addressing the related CVE.

Out guidance remains to remove the JNDI lookup class, or to upgrade to a patched releases:

3

Since our organization will be scanning across the board the idea of making an exception for this component will not be desirable... We also prefer this mitigation because we can verify the integrity of the delivered jar against the checksum as known in the maven repositories.

After replacing the files and their references with the 2.16.0 versions everything seems to be working as expected. We will do more detailed testing with this mitigation as we move forward with testing the rollout.

4

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.