The Apache Log4j2 library has suffered a series of critical security issues (see this page at the Log4j2 project).

Eclipse Jetty by default does not use and does not depend on Log4j2 and therefore Jetty is not vulnerable and thus there is no need for a Jetty release to address this CVE.

If you use Jetty embedded (i.e as a library in your application), and your application uses Log4j2, then you have to take the steps recommended by the CVE to mitigate possible impacts without worrying about the Jetty version.

However, Jetty standalone offers an optional Log4j2 Jetty module.
The following describes how you can test if your Jetty standalone configuration is using Log4j2, and how to upgrade to a fixed Log4j2 version without waiting for a release of Jetty.

IMPORTANT: You must scan the content of your web applications deployed in Jetty, as they may contain a vulnerable Log4j2 artifact. Consult the CVE details to mitigate the vulnerability.

Eclipse Jetty 9

You can see your configuration of Jetty with a --list-modules command in your $JETTY_BASE directory:

$ java -jar $JETTY_HOME/start.jar --list-modules
Enabled Modules:
================
0) bytebufferpool transitive provider of bytebufferpool for server
init template available with --add-to-start=bytebufferpool
1) log4j2-api transitive provider of log4j2-api for slf4j-log4j2
2) resources transitive provider of resources for log4j2-impl
3) log4j2-impl transitive provider of log4j2-impl for slf4j-log4j2
4) slf4j-api transitive provider of slf4j-api for slf4j-log4j2
5) slf4j-log4j2 transitive provider of slf4j-log4j2 for logging-log4j2
6) logging-log4j2 ${jetty.base}/start.d/logging-log4j2.ini
7) threadpool transitive provider of threadpool for server
init template available with --add-to-start=threadpool
8) server ${jetty.base}/start.d/server.ini
9) http ${jetty.base}/start.d/http.ini

Here you can see that the logging-log4j2 module is explicitly enabled and that it transitively depends on log4j2-api.
The following command will show what version of the library is being used:

$ java -jar $JETTY_HOME/start.jar --list-config
Jetty Server Classpath:
-----------------------
Version Information on 13 entries in the classpath.
Note: order presented here is how they would appear on the classpath.
changes to the --module=name command line options will be reflected here.
0: 2.14.0 | ${jetty.base}/lib/log4j2/log4j-api-2.14.0.jar
1: (dir) | ${jetty.base}/resources
2: 3.4.2 | ${jetty.base}/lib/log4j2/disruptor-3.4.2.jar
3: 2.14.0 | ${jetty.base}/lib/log4j2/log4j-core-2.14.0.jar
4: 2.14.0 | ${jetty.base}/lib/log4j2/log4j-slf4j-impl-2.14.0.jar
5: 1.7.32 | ${jetty.base}/lib/slf4j/slf4j-api-1.7.32.jar
6: 3.1.0 | ${jetty.home}/lib/servlet-api-3.1.jar
7: 3.1.0.M0 | ${jetty.home}/lib/jetty-schemas-3.1.jar
8: 9.4.44.v20210927 | ${jetty.home}/lib/jetty-http-9.4.44.v20210927.jar
9: 9.4.44.v20210927 | ${jetty.home}/lib/jetty-server-9.4.44.v20210927.jar
10: 9.4.44.v20210927 | ${jetty.home}/lib/jetty-xml-9.4.44.v20210927.jar
11: 9.4.44.v20210927 | ${jetty.home}/lib/jetty-util-9.4.44.v20210927.jar
12: 9.4.44.v20210927 | ${jetty.home}/lib/jetty-io-9.4.44.v20210927.jar

Here we can see that the vulnerable Log4j2 2.14.0 version is being used.
The following commands will remove that jar and update the Jetty base to use the fixed Log4j2 2.17.0 jar:

$ echo 'log4j2.version=2.17.0' >> start.d/logging-log4j2.ini
$ rm -f lib/log4j2/*
$ java -jar $JETTY_HOME/start.jar --create-files
$ java -jar $JETTY_HOME/start.jar --list-config
Jetty Server Classpath:
-----------------------
Version Information on 13 entries in the classpath.
Note: order presented here is how they would appear on the classpath.
changes to the --module=name command line options will be reflected here.
0: 2.17.0 | ${jetty.base}/lib/log4j2/log4j-api-2.17.0.jar
1: (dir) | ${jetty.base}/resources
2: 3.4.2 | ${jetty.base}/lib/log4j2/disruptor-3.4.2.jar
3: 2.17.0 | ${jetty.base}/lib/log4j2/log4j-core-2.17.0.jar
4: 2.17.0 | ${jetty.base}/lib/log4j2/log4j-slf4j-impl-2.17.0.jar
5: 1.7.32 | ${jetty.base}/lib/slf4j/slf4j-api-1.7.32.jar
6: 3.1.0 | ${jetty.home}/lib/servlet-api-3.1.jar
7: 3.1.0.M0 | ${jetty.home}/lib/jetty-schemas-3.1.jar
8: 9.4.44.v20210927 | ${jetty.home}/lib/jetty-http-9.4.44.v20210927.jar
9: 9.4.44.v20210927 | ${jetty.home}/lib/jetty-server-9.4.44.v20210927.jar
10: 9.4.44.v20210927 | ${jetty.home}/lib/jetty-xml-9.4.44.v20210927.jar
11: 9.4.44.v20210927 | ${jetty.home}/lib/jetty-util-9.4.44.v20210927.jar
12: 9.4.44.v20210927 | ${jetty.home}/lib/jetty-io-9.4.44.v20210927.jar

Eclipse Jetty 10 & 11

You can see your configuration of Jetty with a --list-modules command in your $JETTY_BASE directory:

$ java -jar $JETTY_HOME/start.jar --list-modules
Enabled Modules:
----------------
0) resources transitive provider of resources for logging-log4j2
1) logging/slf4j dynamic dependency of logging-log4j2
transitive provider of logging/slf4j for logging-log4j2
2) logging-log4j2 ${jetty.base}/start.d/logging-log4j2.ini
3) bytebufferpool transitive provider of bytebufferpool for server
init template available with --add-module=bytebufferpool
4) threadpool transitive provider of threadpool for server
init template available with --add-module=threadpool
5) server transitive provider of server for http
init template available with --add-module=server
6) http ${jetty.base}/start.d/http.ini

Here you can see that the logging-log4j2 module is explicitly enabled and that it transitively depends on log4j2-api.   The following command will show what version of the library is being used:

$ java -jar $JETTY_HOME/start.jar --list-config
Properties:
-----------
java.version = 14.0.2
java.version.major = 14
java.version.micro = 2
java.version.minor = 0
java.version.platform = 14
jetty.base = /tmp/test
jetty.base.uri = file:///tmp/test
jetty.home = /opt/jetty-home-11.0.7
jetty.home.uri = file:///opt/jetty-home-11.0.7
jetty.webapp.addServerClasses = org.apache.logging.log4j.,org.slf4j.
log4j.version = 2.14.1
runtime.feature.alpn = true
slf4j.version = 2.0.0-alpha5

Here we can see that the vulnerable Log4j2 2.14.1 version is being used.
The following commands will remove that jar and update the Jetty base to use the fixed Log4j2 2.17.0 jar:

$ echo 'log4j.version=2.17.0' >> start.d/logging-log4j2.ini
$ rm -f lib/logging/*
$ java -jar $JETTY_HOME/start.jar --create-files
$ java -jar $JETTY_HOME/start.jar --list-config
Properties:
-----------
java.version = 14.0.2
java.version.major = 14
java.version.micro = 2
java.version.minor = 0
java.version.platform = 14
jetty.base = /tmp/test
jetty.base.uri = file:///tmp/test
jetty.home = /opt/jetty-home-11.0.7
jetty.home.uri = file:///opt/jetty-home-11.0.7
jetty.webapp.addServerClasses = org.apache.logging.log4j.,org.slf4j.
log4j.version = 2.17.0
runtime.feature.alpn = true
slf4j.version = 2.0.0-alpha5

Jetty Server Classpath:
-----------------------
Version Information on 11 entries in the classpath.
Note: order presented here is how they would appear on the classpath.
changes to the --module=name command line options will be reflected here.
0: (dir) | ${jetty.base}/resources
1: 2.0.0-alpha5 | ${jetty.home}/lib/logging/slf4j-api-2.0.0-alpha5.jar
2: 2.17.0 | ${jetty.base}/lib/logging/log4j-slf4j18-impl-2.17.0.jar
3: 2.17.0 | ${jetty.base}/lib/logging/log4j-api-2.17.0.jar
4: 2.17.0 | ${jetty.base}/lib/logging/log4j-core-2.17.0.jar
5: 5.0.2 | ${jetty.home}/lib/jetty-jakarta-servlet-api-5.0.2.jar
6: 11.0.7 | ${jetty.home}/lib/jetty-http-11.0.7.jar
7: 11.0.7 | ${jetty.home}/lib/jetty-server-11.0.7.jar
8: 11.0.7 | ${jetty.home}/lib/jetty-xml-11.0.7.jar
9: 11.0.7 | ${jetty.home}/lib/jetty-util-11.0.7.jar
10: 11.0.7 | ${jetty.home}/lib/jetty-io-11.0.7.jar

Conclusions

It is recommended that you update any usage of Log4j2 immediately.

Once you upgrade your version of Jetty, you will need to edit the start.d/logging-log4j2.ini file to remove the explicit setting of the Log4j2 version, so that you may use newer Log4j2 versions.

Jetty & Log4j2 exploit CVE-2021-44228

Leave a Reply

Your email address will not be published. Required fields are marked *