Security Bulletin: A vulnerability in Apache Log4j affects IBM InfoSphere Information Server (CVE-2021-44228)

Summary

A vulnerability (Log4Shell) in Apache Log4j used by IBM InfoSphere Information Server was addressed. Various components in Information Server use Log4j to log messages for diagnostics. The fix upgrades log4j to version 2.16.0.

Vulnerability Details

CVEID:CVE-2021-44228
**DESCRIPTION:**Apache Log4j could allow a remote attacker to execute arbitrary code on the system, caused by the failure to protect against attacker controlled LDAP and other JNDI related endpoints by JNDI features. By sending a specially crafted code string, an attacker could exploit this vulnerability to load arbitrary Java code on the server and take complete control of the system. Note: The vulnerability is also called Log4Shell or LogJam.
CVSS Base score: 10
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/214921 for the current score.
CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)

Affected Products and Versions

Information Server 11.5 and 11.3 are affected. Both releases are past end of service.

Remediation/Fixes

Note:
1. You should also apply the fix for other components (WebSphere Application Server, Db2, etc.) in your environment. See the Related information section for relevant bulletins; however, it is best to check the IBM PSIRT blog for any updated information from these components.

2. Information Server saves prior versions of jar files to facilitate patch rollbacks and uninstall of components:

a. In the Updates folder within your Information Server location, for each patch installed, a patch folder is created with the name of the patch. The patch folder contains copies of files that are replaced during the patch install. The patch folder name is based on the name of the patch which can be seen in the History section of your Version.xml. The files in this folder are used by the Update installer to roll back a patch installation; they are not needed while Information Server is used.
b. Each time the Update Installer is updated, the jar files used by the Update Installer that are changed, are saved in a new lib.<timestamp> folder within the Updates folder.
c. The _uninstall folder contains files that are only used while uninstalling Information Server components.

For Apache Log4j related patches, the prior vulnerable versions of Apache Log4j could be present within such folders.
If you want to remove such Apache Log4j files from the system, take a backup of such a folder and then purge the folder.

An appropriate backup of the patch folder must be restored before any subsequent patch rollback attempt.
Likewise, an appropriate backup of the files in _uninstall must be restored before any subsequent uninstall action.

3. (April 27, 2022) In some configurations (such as when the Services tier is separate), Service Pack 3 might not upgrade all files. For that situation, Service Pack 4 should be installed. You can check your Services tier to see whether any log4j jars with version older than 2.17.1 are present.

4. (October 14, 2022) Some open source components usage of log4j version 1 was addressed in Information Server 11.7.1.4.

Workarounds and Mitigations

Note:
1. The following steps can be done to mitigate the vulnerability. However, we strongly recommend applying the fix on top of 11.7.1.3.
2. It is imperative that the mitigation or fix be applied as soon as possible.
3. Information Server saves prior versions of jar files to facilitate patch rollbacks and uninstall of components:

a. In the Updates folder within your Information Server location, for each patch installed, a patch folder is created with the name of the patch. The patch folder contains copies of files that are replaced during the patch install. The patch folder name is based on the name of the patch which can be seen in the History section of your Version.xml. The files in this folder are used by the Update installer to roll back a patch installation; they are not needed while Information Server is used.
b. Each time the Update Installer is updated, the jar files used by the Update Installer that are changed, are saved in a new lib.<timestamp> folder within the Updates folder.
c. The _uninstall folder contains files that are only used while uninstalling Information Server components.

For Apache Log4j related patches, the prior vulnerable versions of Apache Log4j could be present within such folders.
If you want to remove such Apache Log4j files from the system, take a backup of such a folder and then purge the folder.

An appropriate backup of the patch folder must be restored before any subsequent patch rollback attempt.
Likewise, an appropriate backup of the files in _uninstall must be restored before any subsequent uninstall action.

Steps:

1. Applicability of the mitigation steps:

• These steps can be applied to any 11.7 or 11.5 or 11.3 installation.
• If you have a Microservices tier (available since 11.7), follow the instructions in step 8 to mitigate the Microservices tier.

2. Script information:
To mitigate the vulnerability, the JndiLookup.class must be removed from all instances of log4j 2.x jars.
A UNIX script, iis-log4j-mitigation.sh, is provided to make it convenient to remove the class. After using the script, check the system for any log4j instances that contain the class.
For Windows, a PowerShell script, iis-log4j-mitigation.ps1 is provided.
There are other vulnerable classes in log4j 1.x jars, JMSAppender and SocketServer, that were reported in CVE-2021-4104. Information Server releases are not vulnerable to this CVE. However, the script will also remove these classes.
We estimate that the script should take less than 20 minutes to execute.

Usage:
iis-log4j-mitigation.sh -i|-install-dir <path> [-w|-work-dir <working-dir-path>] [-l|-log4j-version <1|2>] [-r|-remove]

iis-log4j-mitigation.sh -help

where
<path> is the absolute path to the InfoSphere Information Server or WebSphere installation location.
You should run the script against each location.
<working-dir-path> is the location for a temporary work directory used by the script.
We estimate that a minimum of 1G disk space is needed in the work directory.
-log4j-version specifies the Apache Log4j version, ‘1’ or ‘2’, to mitigate.
By default, both log4j versions are mitigated. Script version 1.1 or later is needed to use this option.
-remove should be specified to remove the classes.
If not specified, the script will only list the locations where the classes are found.
-help provides information on usage and requirements

3. Backup:
Take a backup of your Information Server and WebSphere Application Server directories.

4. Where to run the script and how to use it:
The script should be run on the Information Server Services, Engine and Client tiers.
The script should also be run against the directory where WebSphere Application Server is located, assuming that it is not in the same directory tree as Information Server.

a. Stop Information Server. Ensure that no Information Server services or processes are running.
b. For each tier/install location, first, run the script without the remove option to list all locations of the classes.
Note the owner of the jars containing these classes.
c. Next, as the jar owner, run the script with the –remove option to remove the classes from these locations.
d. Finally, run the script again without the remove option to check whether any locations are reported.
e. Manually check the system for any log4j instances that contain the classes.
f. Restart Information Server.

5. Pre-requisites:

For UNIX:

Some of the steps in the script need zip, unzip and bash to be run.
You may need to install zip, unzip and bash on UNIX systems.

6. Download script:

Download the script for your platform to a directory that is not in the paths to be scanned.

For UNIX:

_iis-log4j-mitigation.sh _

For Windows:

iis-log4j-mitigation.ps1

After the script is downloaded, examine the script properties (Alt+Enter or right-click -> Properties), and check whether there is a security notification at the bottom of the General tab that indicates:
This file came from another computer and might be blocked to help protect this computer.

If the security notification is present, do one of the following:

• Check the Unblock check box.
  Click Apply.

• or Set the execution policy in the PowerShell window to Unrestricted:

        Set-ExecutionPolicy -ExecutionPolicy Unrestricted
  

You may still be prompted to accept execution of the script each time you run the script.

7. Apply mitigation (Services, Engine, Client tiers):

Perform the following actions on the tier indicated.

Services Tier

Run the script against your services tier location, as indicated in step 4 above.

** Address WebSphere Application Server:**
Run the script against your WebSphere installation location, as indicated in step 4 above.

WebSphere fixes for the log4j vulnerability should be applied per WebSphere security bulletins. They may require upgrading your WebSphere version prior to applying the fix. A list of WebSphere bulletins is provided in the Related Information section.
For advice on various WebSphere security fixes for log4j vulnerabilities, see https://www.ibm.com/support/pages/node/6525860.
a. Apply the latest WebSphere fix (PH42762) for log4j (even if you applied the original fix PH42728).
b. Additionally,
For Liberty profile, apply https://www.ibm.com/support/pages/node/6526824 (PH42759)
For Network Deployment profile, apply https://www.ibm.com/support/pages/node/6528220 (PH42899)

Update Solr if you do not have a Microservices tier:

1. Change directory to <INSTALL_LOCATION>/shared-open-source/solr/install/bin
2. Edit the solr scripts solr.in.sh or solr.in.cmd
   UNIX
   Append _SOLR_OPTS=“$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true”
   _Windows
   Append set SOLR_OPTS=%SOLR_OPTS% -Dlog4j2.formatMsgNoLookups=true
3. Restart the services

LINUX
/shared-open-source/bin/stop-linux-services.sh
/shared-open-source/bin/start-linux-services.sh
AIX
/shared-open-source/bin/stop-aix-services.sh
/shared-open-source/bin/start-aix-services.sh
Windows
/shared-open-source/bin/stop-windows-services.bat
/shared-open-source/bin/start-windows-services.bat

** Engine tier**

Run the script as indicated in step 4 above.

** Client tier**

Run the script as indicated in step 4 above.

8. Apply mitigation (Microservices tier):

If you have the Microservices tier installed, download the archive (ms-tier-log4shell-scripts-0.1.0.tar.gz) to mitigate the vulnerability on the Microservices tier. The archive contains several scripts and a readme file which explains how to use the scripts. You can apply this mitigation even if you applied the instructions in an earlier version of this bulletin.

Copy the archive to a new directory on the system that is running the Microservices tier, uncompress it and extract the contents.

Read the instructions in the README.md file.

Run the scripts under the same user id that installed the Microservices tier (the user id that runs kubectl commands).

Note: The Microservices tier only runs on Linux.

ms-tier-log4shell-scripts-0.1.0.tar.gz