February 7, 2022 Update:
There are additional CVEs in log4j 1.x that have been reported. These include CVE-2022-23302, CVE-2022-23305, and CVE 2022-23307. The first of these two issues is very similar to the issues described below: your log configuration file (for Dodeca, or the Essbase connector) would have to be specifically modified to use one of the esoteric loggers, such as JMSSink or JDBCAppender. In practice we see that very few, if any Dodeca customers are making changes to the logging configuration files that we ship, so the only way to opt in to one of the problematic loggers would be for a customer to specifically do so or for a malicious actor to do it (indicating that the server is already completely compromised).
The third issue (2022-23307) is a little bit different but we don’t believe it represents an issue for customers. In this particular issue, there is a small program that ships with log4j that can be run as a small standalone GUI program. In order to do this you would have to RDP to the server, open a terminal, then issue a particular Java command that would add that JAR file to the class path and then run that particular program. Once in that program (it’s a simple log analyzer), you’d have to use the GUI to load a specific malicious log file and then process it. So, as with the other issues, we don’t believe this represents a practical attack vector that customers need to worry about.
We are gearing up for the imminent release of Dodeca 8.1 that includes some changes to address and improve the log4j situation, namely:
- Dodeca Metadata Server no longer uses log4j at all (log4j 1.x or log4j 2.x). We are using a well known logging library that currently has no known CVEs. Due to having substantially upgraded the logging infrastructure in Dodeca 8.0 already, this change was fairly straightforward.
- Dodeca Essbase Connector (“the Essbase servlet”) ships with and uses the reload4j library. This library is compatible with log4j and is based on the log4j 1.2.17 codebase, but represents a fork by the original author. This updated fork of log4j has all of the known log4j 1.2 CVEs fixed, either through mitigations in the code or removing the offending classes (e.g. the runnable program in CVE-2022-23307 is completely removed).
The bottom line: in the Dodeca 8.1 server component, log4j is completely removed. In the Dodeca 8.1 Essbase connector, log4j has been replaced with reload4j, which is a version of log4j 1.2 with all known CVEs fixed.
December 20, 2021 Update:
A new log4j vulnerability, CVE-2021-45105, was filed related to log4j 2.0-alpha1 through 2.16.0. As Applied OLAP products currently use log4j 1.2.17, this new vulnerability does not apply to our software.
December 16, 2021 Update:
Many people are now aware of a massive vulnerability that was discovered and is being exploited in a very common Java library known as log4j. This vulnerability has been dubbed Log4Shell (CVE-2021-44228). This vulnerability affects versions of Log4j2 between 2.0 and 2.15.0. After careful analysis of our Java web components (Dodeca metadata server, Dodeca Essbase connector, Dodeca HFM connector, and Drillbridge) I can confirm that none of these components use log4J 2.0 and therefore are not vulnerable to this issue.
That said, an earlier version of the log4j library is used in the Dodeca metadata server and Dodeca Essbase connector (but not the other mentioned components). The Dodeca metadata server and Essbase server use log4j-1.2.17.jar. This version of log4j has a few known issues, as reported in CVE-2020-9488, CVE-2019-17571, and CVE-2021-4104. It is highly unlikely that these components are affected by these issues. If your organization has not modified the logging configuration (the log4j.properties file that is inside of dodeca.war or dodeca-essbase.war) then we believe that there is no exposure to these issues.
- The first issue (CVE-2020-9488) only applies if your logging configuration has been modified specifically to use a logger known as an SMTP appender, meaning that your logging configuration has been modified to send logs through email. We have never set this up or seen this in a customer installation.
- The second issue (CVE-2019-17571) has to do with a vulnerability in a Java class named SocketServer. As with the previous issue, it only applies if your logging configuration has been modified to specifically include that logger type. We have never set this up or seen this in a customer installation.
- The third issue (CVE-2021-4104) has to do with a vulnerability in a Java class named JMSAppender. As with the others, it only applies if your logging configuration has specifically been modified to use JMSAppender and has been configured with your own JMS service such as ActiveMQ. Again, we have never set this up or seen this in a customer installation.
The next point release update in the Dodeca 7.x line is Dodeca 7.8.9. This release contains a handful of fixes for other issues and will also ship with a modified version of the log4j 1.2.17 library that specifically excludes the JMSAppender and SocketServer classes. Although we don’t believe there is any current exposure to these issues, we are removing the classes as an extra measure. This post will be updated when 7.8.9 is available. If you wish to modify your existing Dodeca deployments (either Dodeca 7.x or 8.x) in order to remove the impacted classes, please contact us for detailed instructions.
Starting with Dodeca 8.1, we plan to remove log4j from the product.
This post will be updated with additional details as they become available.
