GraphDB Users Ask: Do You Have Any Advice on the Log4j Vulnerability for Different Versions of GraphDB?

ONTOTEXT ANSWER:

A zero-day vulnerability is probably one of the most stressful situations for any operations team, especially when dealing with a vulnerability with the highest severity remote code execution (RCE). The situation is much worse if the vulnerable library (in this case Apache Log4j)  is widespread in thousands of applications such as Elasticsearch, Apache Solr, Apache SPARK and a very long list of commercial software using the same library.

This is exactly what happened this weekend with the announced CVE-2021-44228, where an attacker can force the targeted application via the log4j library to open a malicious JNDI server and load a class file supplied by the attacker.

What are the preconditions to exploit Log4Shell vulnerability?

The full extent of the vulnerability is still under revision. What we know so far is that the attacker can exploit it if:

• The target application uses Apache Log4j from version 2.0-beta 9 up to version 2.14.1 – the check is pretty simple. You need to scan your jar for log4j-core.jar and match its version.
• If you run a Java virtual machine lower than 8. The listed builds below are not directly affected, but still advisable to fix the vulnerability:
  • Java 8 – 8u192
  • Java 11 – 11.0.2

What is the impact on GraphDB software?

The simplest test to check if a Java application is affected by the vulnerability is to check its classpath. Note, this check may not work for every software application if the developers decided to apply the wrong practices of repackaging the JAR files, which is not the case in GraphDB.

graphdb-ee-9.10.1 find . -name '*log4j*' 
./lib/log4j-over-slf4j-1.7.31.jar
./lib/plugins/elasticsearch-connector/log4j-to-slf4j.jar
./lib/plugins/elasticsearch-connector/log4j-core.jar
./lib/plugins/elasticsearch-connector/log4j-api.jar

The quick test indicates that the GraphDB engine does not use Log4j since our logging framework is Logback (a reimplementation of Apache Log4j, which claims faster performance and better usability). The library `./lib/log4j-over-slf4j-1.7.31.jar` is a facade to Logback which routes all code expecting the Log4j classes to the safe Logback implementation.

Unfortunately, the code base of Elasticsearch Connector references the vulnerable log4j-core. After a quick git history test, we see that all GraphDB EE versions between 6.0-9.10 ship the vulnerable Apache Log4j version from 2.6 to 2.8. The deeper code analysis, however, shows that these libraries are used only in the very rare case of running the GraphDB Elasticsearch Connector outside of the database context i.e. only testing the compatibility between GraphDB and the different Elasticsearch server versions.

Our recommendation to all clients who are concerned about these libraries is that they can safely delete them since they will never be instantiated during standard database use. The only case to instantiate the included Apache Log4j is via an Ontotext provided test client, which is not shipped as part of the main codebase.

Conclusion

All GraphDB editions from 6.x to 9.x are completely immune to the reported Log4Shell vulnerability (CVE-2021-44228) because the database uses the Logback logging framework. Sadly, the GraphDB EE will fail during automatic checks because of the shipped Apache Log4j libraries distributed in the Elasticsearch Connector. This library is absolutely safe and will be instantiated only when the Connector is in Elasticsearch search compatibility test mode. This mode is not part of the GraphDB EE distribution and our team will remove these dependencies to prevent false positive alarms.

Did this help you solve your issue? Your opinion is important not only to us but also to your peers.