Overview :

As you may have seen in the news lately on Thursday December 9th, a new Zero-Day exploit has been reported against the popular Java logging Log4j2 librairy which can allow an attacker to remotely execute code. This vulnerability has been reported with CVE-2021-44228 against the log4j-core jar which has been fixed in Log4J v2.15.0.

CVE-2021-44228 is a vulnerability classified under the highest severity mark, i.e. 10 out of 10.

What versions of Log4J are affected by this security vulnerability?

Affected versions:

• Apache Log4J versions 1.x : subject to special configuration
• Apache Log4J versions 2.0 to 2.14.1

Does ARender affected by this security vulnerability?

ARender V3 (3.1.x):

In this versions, ARender uses log4j-1.2.16 on both HMI and Rendition.

As log4j 1.x does not offer a JNDI lookup mechanism at the message level, it is not affected by CVE-2021-44228.

However, log4j 1.x comes with JMSAppender which can perform a JNDI lookup if it is enabled in the log4j’s configuration file (log4j.properties or log4j.xml). Therefore, a attacker who can write to the application log4j’s configuration file can perform a remote code execution (RCE).

ARender V4 (4.x.x):

On the other hand in ARender V4, ARender uses different logging librairy for the Web UI (HMI) and the Rendition. For the Web UI, it uses log4j-1.2.17 and for the Rendition it uses logback-1.2.3.

The ARender rendition consists of several Spring Boot microservices, using the logback library by default. The log4j-to-slf4j and log4j-api libraries included in Spring Boot cannot be exploited on their own. After the first analyzes made on our microservices, a log4j-core (2.12.1) dependency is found in the TaskConversion microservice (service allowing document conversions). Tests were carried out on this service in order to reproduce the security flaw which concluded that the service in question was not affected.

How to solve that?

By default, in ARender V3, the log4j’s configuration file does not enabled the JMSAppender. Since log4j 1.x is not vulnerable at message level but at configuration file, if you have a custom log4j’s configuration file that overrides the default one, we recommand that configuration files be protected against writing. They should be read-only for all users.

As we mentioned above, ARender V4 does not seem to be affected by the security vulnerability however, the fact that one of the microservices has a dependency on the log4j-core library it is strongly recommended that you set the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true in order to mitigate the flaw.

Note : We will release a patch on ARender 4.7.x version to remove the reference to this dependency (log4j-core)