Impact of Log4j vulnerability on NavVis IVION

A severe security vulnerability has been discovered in the popular Java logging library Log4j, allowing attackers, which can control a part of a message written to the log, to take over the server. There are many ways how attackers can control the content of a message written to the log. In the case of NavVis IVION (and generally with any application), it can be assumed that it's trivial to do that, even for anonymous users, and even with private mode enabled.

To exploit the vulnerability, an attacker needs to:

• find a system that is vulnerable in general (i.e. Log4j version < 2.15).

• find an attack vector that works (i.e., a particular message that is logged that triggers the vulnerability).

From [2]:

"JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector. In these versions com.sun.jndi.ldap.object.trustURLCodebase is set to false meaning JNDI cannot load a remote codebase using LDAP."

All our Docker IndoorViewer/IVION releases, since the very first one (2.5.1), had at least OpenJDK 11.0.4. This means that this attack vector was not possible. However, there are other attack vectors targeting this vulnerability which can result in Remote Code Execution (RCE), meaning vulnerability. Therefore, updating OpenJDK to >11.0.1 is not sufficient. The vulnerability itself has been addressed and fixed in Log4j in version 2.15.0. With IVION 10.2.3, we have updated the Log4j version we use to 2.15.0. After updating to 10.2.3, no other measure is required.

If updating is not possible, [1] suggests:

"Users who cannot upgrade to 2.15.0 can mitigate the exposure by:

• Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command line option or add log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event messages."

We will address the issue in older versions of IVION (e.g. 10.1.x) and IndoorViewer (e.g. 2.8.x) by setting the option -Dlog4j2.formatMsgNoLookups=true. 

NavVis IVION in Docker

For NavVis IVION/IndoorViewer running on-premise in Docker, this option can be set by editing docker-compose.yml and adding JAVA_OPTS as follows:

services:

#...
iv:
entrypoint: ["java", "-jar", "/opt/NavVis/web/view.jar", "--spring.profiles.active=docker", "-Dlog4j2.formatMsgNoLookups=true"]
entrypoint: ["java", "-jar", "/opt/NavVis/web/view.jar", "--spring.profiles.active=docker", "-Dlog4j2.formatMsgNoLookups=true"]

Then, stop the containers docker-compose down and bring them back up docker-compose up -d. Verify that the option has been set by running docker-compose exec iv xargs -0 -L1 -a /proc/1/cmdline. The output must contain the following line

-Dlog4j2.formatMsgNoLookups=true

Note: this parameter requires Log4j with version >= 2.10.0. We have confirmed that IndoorViewer 2.5.1 was using Log4j 2.11.2, so this fix should work for all Docker releases of NavVis IndoorViewer.

NavVis IVION package-based installation

Edit /etc/default/jetty9. Modify it to set the parameter -Dlog4j2.formatMsgNoLookups=true:

JAVA_OPTIONS="-Dlog4j2.formatMsgNoLookups=true"

Then restart Jetty by running service jetty9 restart. Verify that the option has been set by running ps ax | grep java. The output must contain a line like:

java ... -Dlog4j2.formatMsgNoLookups=true ...

References

• [1] https://logging.apache.org/log4j/2.x/

• [2] https://www.lunasec.io/docs/blog/log4j-zero-day/

• [3] IBM Randori Recon

• [4] https://issues.apache.org/jira/browse/LOG4J2-3198 (fix that went into log4j 2.15.0)

• [5] https://issues.apache.org/jira/browse/LOG4J2-2109 (the temporary mitigation that went into log4j 2.10 in 2017)