Investigation of Log4j Vulnerability with Clarity LIMS

12/21/2021


On December 10, 2021 Illumina was made aware of a vulnerability in the Apache Log4j software suite. This software component is a Java-based logging utility and part of the Apache Logging Services Foundation products. Illumina uses this software as part of the Clarity LIMS product in both Cloud Software-as-a-Service and on-premises installations at customer sites.

After we became aware of the issue, we launched an investigation and have the following update:

  • A vulnerable component in the Illumina Cloud-Hosted environment v.5.2-5.4 was identified, customers were notified, and the issue was patched during the regularly scheduled maintenance window. No further action is required for Cloud-Hosted customers.
  • On-premise customers with v.5.2 were notified and are advised to apply the critical software patch described in the following sections.

Issues addressed:

Illumina takes data privacy and security issues very seriously, and we hope this information helps alleviate any concerns about this vulnerability. If you have any questions, contact techsupport@illumina.com.

Background

Vulnerabilities CVE-2021-44228 and CVE-2021-45046 were found to impact any applications (via Remote Code Execution (RCE)) using Apache Log4j 2. The vulnerability impacts Apache Log4j versions 2.0 to 2.14.1.

The affected Apache Log4j 2 versions were used in the following dependencies for released Clarity LIMS version 5.2 and above:

No Dependency Apache Log4j 2 version Affected released Clarity LIMS versions
1 Elasticsearch 6.2.4 2.9.1 5.2, 5.3, 5.4
2 Search Indexer 2.10.0

 

Summary of Patch

The main changes involve the removal of JndiLookup class from the log4j-core.jar, which is the target of the security vulnerability.

Clarity LIMS Functionality Impact

The affected dependencies contribute to the search functionality of Clarity LIMS system. Therefore, it is advisable to stop the Clarity services on the server instance before the change.

Instructions for Applying the Patch

Prerequisites

  • Make sure to have root user access to the server instance (all the following commands should be executed with root user access).
  • Make sure that the server is installed with zip utility. A zip command can be issued in the terminal to verify the install. The following will be observed if the utility is not installed:
     
    zip: command not found

Instructions

  1. Stop all the Clarity services on the server instance before the change.
     
    /opt/gls/clarity/bin/run_clarity.sh stop
  2.  
  3. JndiLookup class removal for Elasticsearch 6.2.4:
    1. Make sure that the JndiLookup.class exists in the log4j-core-2.9.1.jar used for Elasticsearch 6.2.4:
       
      jar tvf /usr/share/elasticsearch/lib/log4j-core-2.9.1.jar | grep -i JndiLookup
       
      Expected example output:
       
      2937 xxx xxx xx xx:xx:xx GMT xxx
      org/apache/logging/log4j/core/lookup/JndiLookup.class
    2.  
    3. Back up the log4j-core-2.9.1.jar to a designated directory. Make sure that the zip is created in the backup directory:
       
      zip <BACKUP_DIRECTORY>/backup-log4j-core-es.zip/usr/share/elasticsearch/lib/log4j-core-2.9.1.jar
    4.  
    5. Remove the JndiLookup.class from the log4j-core-2.9.1.jar:
       
      zip -d /usr/share/elasticsearch/lib/log4j-core-2.9.1.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
       
      Expected example output:
       
      deleting: org/apache/logging/log4j/core/lookup/JndiLookup.class
       
      NOTE: If running the previous command produces a series of lines that look like the following, this has no effect on the removal of the vulnerable class and can safely be ignored:
       
      zip warning: Local Version Needed To Extract does not match CD: org/apache/logging/log4j/core/util/WatchManager$WatchRunnable.class
    6.  
    7. Verify if JndiLookup.class is removed:
       
      jar tvf /usr/share/elasticsearch/lib/log4j-core-2.9.1.jar | grep -i JndiLookup
       
      No expected output from the command.
    8.  
  4. JndiLookup class removal for Search Indexer:
    1. Make sure that the JndiLookup.class exists in the log4j-core-2.10.0.jar used for Search Indexer:
       
      jar tvf /opt/gls/clarity/search-indexer/lib/log4j-core-2.10.0.jar | grep -i JndiLookup
       
      Expected example output:
       
      2937 xxx xxx xx xx:xx:xx GMT xxx
      + org/apache/logging/log4j/core/lookup/JndiLookup.class

    2.  
    3. Back up the log4j-core-2.10.0.jar to a designated directory. Make sure that the zip is created in the backup directory:
       
      zip <BACKUP_DIRECTORY>/backup-log4j-core-searchindexer.zip /opt/gls/clarity/search-indexer/lib/log4j-core-2.10.0.jar
    4.  
    5. Remove the JndiLookup.class from the log4j-core-2.10.0.jar:
       
      zip -d /opt/gls/clarity/search-indexer/lib/log4j-core-2.10.0.jar
      org/apache/logging/log4j/core/lookup/JndiLookup.class

       
      Expected example output:
      The output should include the following line as output:
       
      deleting: org/apache/logging/log4j/core/lookup/JndiLookup.class
       
      NOTE: If running the previous command produces a series of lines that look like the following, this has no effect on the removal of the vulnerable class and can safely be ignored:
       
      zip warning: Local Version Needed To Extract does not match CD: org/apache/logging/log4j/core/util/WatchManager$WatchRunnable.class
    6.  
    7. Verify if JndiLookup.class is removed:
       
      jar tvf /opt/gls/clarity/search-indexer/lib/log4j-core-2.10.0.jar | grep -i JndiLookup
       
      There should be no output from the command.
     
  5. Start the Clarity services on the server instance and verify if UI is accessible:
     
    /opt/gls/clarity/bin/run_clarity.sh start

References