December 12, 2021
A high severity vulnerability (CVE-2021-44228, CVSSv3 10.0) impacting multiple versions of the Apache Log4j 2 utility was disclosed publicly on December 9, 2021. The vulnerability allows for unauthenticated remote code execution (RCE). This vulnerability exists in Apache Log4j 2 versions 2.0 to 2.14.1. According to the developer, version 1.x of Log4j is not susceptible to this vulnerability.
Log4j 2 is an open-source Java logging library developed by the Apache Foundation. Log4j 2 is widely used in many applications as a dependency. These include numerous cloud services as well as enterprise applications such as Dualshield.
Generally speaking, DualShield is not susceptible to this vulnerability.
1. DualShield 5.x, DualShield 6.1, 6.2, 6.3 includes Log4j 1.x which is not susceptible to this vulnerability
2. DualShield 6.4 includes Log4j 2.14. However, DualShield 6.4 includes JRE 8u203 which is not susceptible to Remote Code Execution (RCE).
According to this article, and this blog post, if the server has Java runtimes later than 8u121, then it is protected against remote code execution via JNDI.
Actions recommended to DualShield customers
In general, you should always upgrade your DualShield to the latest update as soon as possible. If you are running DualShield 6.4 and cannot upgrade to the latest update 6.4.20.1212 immediately, then you should add "log4j2.formatMsgNoLookups=true" into the JAVA system environment and restart the DualShield service after the change.
Actions taken by the DualShield team
To ensure that DualShield is absolutely free from this vulnerability, an update of DualShield was produced and released today, DualShield 6.4.20.1212.
In this update, we have made the following changes:
1. Log4j is completely removed from the SSO server (the frontend) in the DualShield platform
2. Log4j 2 is completely removed from the authentication server (the backend) in the DualShield platform. Log4j 1.2.17 is kept as it can't be easily upgraded yet, but it is not susceptible to this vulnerability.
3. Log4j 2 in the certificate server (frontend) has been upgraded to the latest log4j 2.15 which has fixed this vulnerability.