log4j in Elasticsearch container

growi-docker-compose/elasticsearch/Dockerfile

FROM docker.elastic.co/elasticsearch/elasticsearch:6.8.10

このバージョンはlog4jの脆弱性に関して大丈夫なのでしょうか？

$ docker run -it --rm docker.elastic.co/elasticsearch/elasticsearch:6.8.10 bash
[root@f9648cedf22a elasticsearch]# find -name "*log4j*"
./lib/log4j-core-2.11.1.jar
./lib/log4j-1.2-api-2.11.1.jar
./lib/log4j-api-2.11.1.jar
./config/log4j2.properties
./modules/x-pack-security/log4j-slf4j-impl-2.11.1.jar

Oh...

https://www.jpcert.or.jp/at/2021/at210050.html

Log4jバージョン2.10およびそれ以降

Log4jを実行するJava仮想マシンを起動時に「log4j2.formatMsgNoLookups」
というJVMフラグオプションを指定する

環境変数「LOG4J_FORMAT_MSG_NO_LOOKUPS」を「true」に設定する

elastic/elasticsearch#81618 (comment)

This can be mitigated for the time being by adding -Dlog4j2.formatMsgNoLookups=true to ES_JAVA_OPTS

growi-docker-compose/docker-compose.yml

Lines 51 to 53 in ef34ee5

    
           environment: 
        
             - bootstrap.memory_lock=true 
        
             - "ES_JAVA_OPTS=-Xms256m -Xmx256m"  # increase amount if you have enough memory

6.8・7.16・8.0（ベータ）のコンテナ全てlog4j2.11.1

当初案内されていた LOG4J_FORMAT_MSG_NO_LOOKUPS を含む一部の回避策は、攻撃を防ぐには不十分であったと判明したようで、脆弱性に対応した 6.8.21 を使用するのが根本対策になりそうです。

https://logging.apache.org/log4j/2.x/security.html

Older (discredited) mitigation measures

This page previously mentioned other mitigation measures, but we discovered that these measures only limit exposure while leaving some attack vectors open.

Other insufficient mitigation measures are: setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the logging configuration to disable message lookups with %m{nolookups}, %msg{nolookups} or %message{nolookups} for releases >= 2.7 and <= 2.14.1.

@hayao-k 6.8.21のコンテナの中身を見てみましたが、log4jは2.11.1ですね

とはいえ対策済みみたいです。
elastic/elasticsearch#81863

Users may upgrade to Elasticsearch 7.16.1 or 6.8.21, 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.

	environment:
	- bootstrap.memory_lock=true
	- "ES_JAVA_OPTS=-Xms256m -Xmx256m" # increase amount if you have enough memory