Upgrade log4j in Docker images
tats-u opened this issue · 7 comments
Elasticsearch version (bin/elasticsearch --version):
7.16.1 / 6.8.21
Plugins installed: []
JVM version (java -version):
OS version (uname -a if on a Unix-like system):
Description of the problem including expected versus actual behavior:
Steps to reproduce:
Please include a minimal but complete recreation of the problem,
including (e.g.) index creation, mappings, settings, query etc. The easier
you make for us to reproduce it, the more likely that somebody will take the
time to look at it.
docker run -it --rm elasticsearch:6.8.21 bash/docker run -it --rm elasticsearch:7.16.1 bashfind -name "*log4j*"
Provide logs (if relevant):
6.8.21
./config/log4j2.file.properties
./config/log4j2.properties
./lib/elasticsearch-log4j-7.16.1.jar
./lib/log4j-api-2.11.1.jar
./modules/repository-url/log4j-1.2-api-2.11.1.jar
./modules/x-pack-identity-provider/log4j-slf4j-impl-2.11.1.jar
./modules/x-pack-core/log4j-1.2-api-2.11.1.jar
./modules/vector-tile/log4j-slf4j-impl-2.11.1.jar
./modules/x-pack-security/log4j-slf4j-impl-2.11.1.jar
7.16.1
./config/log4j2.file.properties
./config/log4j2.properties
./lib/elasticsearch-log4j-7.16.1.jar
./lib/log4j-api-2.11.1.jar
./modules/repository-url/log4j-1.2-api-2.11.1.jar
./modules/x-pack-identity-provider/log4j-slf4j-impl-2.11.1.jar
./modules/x-pack-core/log4j-1.2-api-2.11.1.jar
./modules/vector-tile/log4j-slf4j-impl-2.11.1.jar
./modules/x-pack-security/log4j-slf4j-impl-2.11.1.jar
Why are they both 2.11.1, not 2.15 or 2.16? Are you really not up for maintaining Docker images?
@tats-u if you examine these jar files, the JndiLookup class has been removed e.g.
for jar in $(find -name log4j\*.jar ) ; do zipinfo $jar | grep -i jndi; done
Docker Hub's scanning understands the remediations that are in place, and marks the images with "Log4Shell CVE not detected":
https://hub.docker.com/_/elasticsearch?tab=tags
For the latest updates on this issue, please refer to https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476
Elastic's security reporting guidelines are available at https://www.elastic.co/community/security. Per those guidelines, all reports of potential security issues or vulnerabilities should be sent via email to security@elastic.co. We are unable to discuss potential issues of this nature here. Please send your report to the email address above, where it can be appropriately handled.
@pugnascotia I am relieved to hear that.
I would send an email if it were unknown, and was wondering whether to do it because it is too famous to be hidden (maybe becomes FAQ).
I will send an email the next time.
And I would appreciate it if you would declare that these versions are resistant to log4shell clearly in https://hub.docker.com/_/elasticsearch and so on.
Users may upgrade to Elasticsearch 7.16.1 310 or 6.8.21 193, which were released on December 13, 2021. These releases do not upgrade the Log4j package, but mitigate the vulnerability by setting the JVM option 3.7k -Dlog4j2.formatMsgNoLookups=true and remove the vulnerable JndiLookup class from the Log4j package.
Do we still have to add LOG4J_FORMAT_MSG_NO_LOOKUPS=true to environment if a custom ES_JAVA_OPTS is passed?
Elasticsearch passes -Dlog4j2.formatMsgNoLookups=true to the JVM by default from v7.16.1. You can read about all the mitigations we have in place by v7.16.2 in our latest blog post on the subject.
@pugnascotia Is it not really overwritten by environment variables (e.g. ES_JAVA_OPTS="-Xms2048m -Xmx2048m -Danother.someOptionName=value") except for -Dlog4j2.formatMsgNoLookups=false passed by e.g. environment in docker-compose.yml?
I'm sorry, I'm don't understand your question.
Elasticsearch constructs a list of all options to pass to the JVM, and populates this list from a variety of sources. The option -Dlog4j2.formatMsgNoLookups=true is now always added into the list of JVM options towards the start. You would need to explicitly set e.g. ES_JAVA_OPTS="-Dlog4j2.formatMsgNoLookups=false" or put -Dlog4j2.formatMsgNoLookups=false into a file under config/jvm.options.d to undo it.
Does that help?
@pugnascotia Yes, very much so. I am so glad that I found out that the latest Elasticsearch containers are safe unless you tread on a lion/tiger's tail i.e. pass -Dlog4j2.formatMsgNoLookups=false. Thank you for resolving my questions.