Security Bulletin
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
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
| Affected Product(s) | Version(s) |
| InfoSphere Information Server, Information Server on Cloud | 11.7, 11.5, 11.3 |
Information Server 11.5 and 11.3 are affected. Both releases are past end of service.
Remediation/Fixes
| Product | VRMF | APAR | Remediation/First Fix |
| InfoSphere Information Server, Information Server on Cloud | 11.7 | JR64358 | --Apply IBM InfoSphere Information Server version 11.7.1.0 --Apply IBM InfoSphere Information Server version 11.7.1.3 --Apply Information Server 11.7.1.3 Service pack 1 |
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
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:
You may need to install zip, unzip and bash on UNIX systems.
6. Download script:
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.
- Check the Unblock check box.
Click Apply.
- or Set the execution policy in the PowerShell window to Unrestricted:
Set-ExecutionPolicy -ExecutionPolicy Unrestricted
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:
- Change directory to <INSTALL_LOCATION>/shared-open-source/solr/install/bin
- 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 - 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):
Get Notified about Future Security Bulletins
References
Change History
16 Dec 2021: Initial Publication
17 Dec 2021: Updated bulletin to indicate that mitigation can also be done on 11.7.1.1 and 11.7.1.2 installations
Additional command needs to be executed on Microservices tier for platform-services sts elasticsearch
Fix will be applicable to 11.7.1.3 installations.
Added Related WebSphere security bulletins
18 Dec 2021: 11.5 release is affected
20 Dec 2021: On AIX, zip may have to be installed in order to do some of the steps. Clarified possible break in product features.
21 Dec 2021: If no Microservices tier, for Solr, an AIX specific script must be used to restart shared open source components
Add 6528220 and 6526824 to the list of relevant WebSphere bulletins; stops loading of JndiLookup class
Microservices tier mitigation is limited to 11.7.1.1 Service Pack 2 and 11.7.1.3 installations
22 Dec 2021: Steps updated with new script, no need to set custom properties or environment flags, coverage for 11.7, 11.5, 11.3
23 Dec 2021: Mitigation script for Windows added; clarification regarding Db2 security bulletin added.
24 Dec 2021: Updated the instructions for mitigating the Microservices tier.
28 Dec 2021: Updated taxonomy, updated description and information of WebSphere fixes
30 Dec 2021: Owner of jar should run the script, Windows script replaced with manual steps
31 Dec 2021: Not vulnerable to CVE-2021-4104 but the script will remove the related classes
Updated script iis-log4j-mitigation.sh: new option -log4j-version to mitigate specific version of log4j
06 Jan 2022: Fix published for 11.7.1.3
07 Jan 2022: Updated summary to indicate that the fix deploys log4j 2.16.0
11 Jan 2022: Removed caution that product features may break with the mitigation/fix, as no such occurrence
Added new mitigation script for Windows that does not use zip and unzip
Backup and purge the Updates folder if you want to remove vulnerable log4j jars from there
14 Jan 2022: Also, backup and purge the _uninstall folder to remove vulnerable log4j jars from there
18 Jan 2022: Removed caution that mitigation does not cover all relevant situations
20 Jan 2022: Removed link to original WebSphere bulletin, added pointer to Related information section and blog
21 Jan 2022: Changed title of step 1 from "Upgrade IBM InfoSphere Information Server" to "Applicability of the mitigation steps"
26 Jan 2022: Updated 1.2 version of Windows mitigation script has better error handling of some situations
27 April 2022: Complete fix is in 11.7.1.3 Service pack 4
28 April 2022: Clarified configurations that need Service pack 4
03 May 2022: Updates/backup and _uninstall/Backup folders should be purged; not the entire Updates & _uninstall folders
31 May 2022: Clarified patch folder is created in Updates location, not a folder named backup
14 Oct 2022: Some open source components usage of log4j version 1 was addressed in 11.7.1.4.
*The CVSS Environment Score is customer environment specific and will ultimately impact the Overall CVSS Score. Customers can evaluate the impact of this vulnerability in their environments by accessing the links in the Reference section of this Security Bulletin.
Disclaimer
Review the IBM security bulletin disclaimer and definitions regarding your responsibilities for assessing potential impact of security vulnerabilities to your environment.
Document Location
Worldwide
Was this topic helpful?
Document Information
Modified date:
14 October 2022
UID
ibm16527372