Overview

Radiant Logic considers information security to be of utmost importance and works diligently to identify and remediate vulnerabilities identified either in our products or in their configurations. 

We have identified a vulnerability within a 3rd party library (Apache Log4j 2) used by Radiant Logic. Security researchers have published an exploit of this library that allows for unauthenticated remote code execution. We strongly encourage impacted customers to implement the mitigation guidance included in the attached advisory immediately. 

We recognize that RadiantOne typically holds, processes or has access to highly sensitive data and mission critical systems, and for that reason we’ve taken immediate action to address this issue. 

Please see the attached guidance for further information. 

Q&A

Q:  What versions & configurations are impacted?

A:  Customers using RadiantOne versions 7.2.x or 7.3.x (Older versions like 7.1.x and 6.x use much older Log4j libraries that didn’t have the JNDI lookup and are not vulnerable).

Q: Do I need to patch anything with regards to Zookeeper? What if I use an external ZooKeeper?

A: Zookeeper uses an older version of Log4j and is not affected by the CVE 2021-44228 vulnerability.

Q: Are RadiantOne 7.1 and older versions affected?

A: No. RadiantOne 7.1 and older versions use an older version of the Log4J library that is not affected by the CVE 2021-44228 vulnerability. These older versions of Log4j did not have the JNDI lookup functionality which is the source of the exploit.

Please direct further questions to support@radiantlogic.com

External References:

National Vulnerability Database - https://nvd.nist.gov/vuln/detail/CVE-2021-44228

Apache Log4j - https://logging.apache.org/log4j/2.x/security.html

Mitigation Guidance 

Our mitigation approach follows the official recommendation from Apache Log4j 2 (see CVE-2021-44228 section on https://logging.apache.org/log4j/2.x/index.html) for any version of the log4j-core-2.x jar that is between 2.0 and 2.10, which is the case in RadiantOne 7.2 and 7.3. This approach removes the JndiLookup class from the log4j-core jar file, which effectively disables the exploit.

Steps To Perform:

The following JAR patching steps must be performed on every server node in a RadiantOne cluster. This requires stopping all nodes in the cluster before applying the mitigation on individual servers. This process will create a temporary outage on that cluster.

NOTE: if you have multiple clusters, then these steps can be performed on one cluster at a time, allowing other clusters to service clients.

You should also take care to stop and start your services using the following best practices:

1.   From the Main Control Panel -> Dashboard tab, take note of the Cloud ID and Server for the    current RadiantOne leader node (noted with the yellow triangle).
2.   Run the following command on ALL the follower nodes one at a time in the cluster $RLI_HOME\bin\advanced\stop_servers.bat (.sh on Linux).
3.   Check any lingering java processes associated with RadiantOne components. Stop any that remain.
4.   Run the following command on the Leader node                       $RLI_HOME\bin\advanced\stop_servers.bat (.sh on Linux)
5.   Check and Kill any lingering java processes associated with RadiantOne components.
6.   Apply the mitigation as outlined in the JAR Patching Steps section below, on ALL the nodes.
7.   Start Control Panel (Jetty) on all the nodes. 
8.   Start RadiantOne FID on the previous leader first (the one you noted in Step 1 above) and then start it on ALL the follower nodes one at a time.
9.   Start JMS and ICS Agent (which starts GlassFish in a cluster) if applicable to your deployment.

JAR Patching Steps

Radiant Logic provides 2 scripts: one for Linux (bash shell script) and one for Windows (Powershell script) that take care of automatically patching all potentially offending log4j-core-2.x jar files. These scripts can also be used to confirm whether the log4j jar files have already been patched. All Radiant Logic components should be stopped prior to running these scripts.

The scripts can be found at the following location:

https://radiantlogicinc246.sharefile.com/d-sebcf68fbfece4d9e8597eaf0eb39932e

Optional: if you prefer not to use the provided scripts, you can follow the manual steps listed below. 

Patch the log4j-core-2.x.jar file (There are up to 2 separate locations where this process must be done, depending on your RadiantOne version. If you don’t see the files at those locations, you don’t need to worry about it). Depending on your version of RadiantOne, this jar file could have a different version number, but the same process applies.

Locations:

• $RLI_HOME/lib/log4j-core-2.7.jar
•  $RLI_HOME/appserver/glassfish/domains/domain1/lib/log4j-core-2.7.jar

For Each Location:

1.     Perform a backup copy of the log4j-core jar file before beginning the removal process. 
2.     Remove the offending class (org/apache/logging/log4j/core/lookup/JndiLookup.class) from the jar file using the provided command:

On Linux (command line):  

zip -q -d $RLI_HOME/lib/log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

On Windows (command line): 

You will need a command line zipping tool such as 7-Zip (https://www.7-zip.org), or the Linux zip command.

7z d %RLI_HOME%\lib\log4j-core-2.7.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

For Versions 7.3.17 and above, the following extra step is required:

1. Delete the folder $RLI_HOME/vds_server/work/docs
2. Move the file $RLI_HOME/apps/web/docs.war to $RLI_HOME/apps/web/disabled