IBM Support

Advice on responding to CVES CVE-2021-44228, CVE-2021-4104 and CVE-2021-45046 for users of WebSphere Application Server traditional or Liberty

News


Abstract

Advice for users of WebSphere Application Server traditional and Liberty working to remediate risks associated with log4j CVES CVE-2021-44228, CVE-2021-4104 and CVE-2021-45046

Last updated: Fri Mar 25 14:55:45 UTC 2022

Content

Frequently asked Questions on the WebSphere Application Server Bulletin for log4j (CVE-2021-44228, CVE-2021-4104, CVE-2021-45046)
 
Q1. Is WebSphere Application Server affected by these vulnerabilities?
A1. Yes, please refer to this security bulletin for details on how to apply the fix. 
 
Note PH42762 (CVE-2021-4104 and CVE-2021-45046) completely supersedes the previous bulletin and fix PH42728. If you have not already installed PH42728 you only need to install PH42762. If you've already installed PH42728, install PH42762 too. The same logic applies if you are following the mitigation steps.  
PH42759/PH42899 below provide an extra layer of protection, by preventing customers' applications from loading the vulnerable Log4j class, if they have Log4j in their applications or shared libraries.
 
Q2. Do I need to follow the instructions for the previous bulletin first?
A2. No, the bulletin and fix for PH42762 (CVE-2021-4104 and CVE-2021-45046) completely supersedes the previous bulletin and fix. If you have not already installed PH42728 you only need to install PH42762. If you've already installed PH42728, install PH42762 too. The same logic applies if you are following the mitigation steps.
Q3. I've installed PH42762 does that mean my applications are no longer vulnerable?
A3. This APAR only addresses the log4j used by the admin console and UDDI. If your applications make use of log4j they may still be vulnerable. For some help in this area, see the later section of this document.

Q4. We have noticed that Installation Manager contains ant-apache-log4.jar how can we remediate this? File-path is: plugins/org.apache.ant_1.9.6.v201510161327/lib/ant-apache-log4j.jar
A4. It doesn't require remediation. This jar does not contain log4j at any version. It includes code to use log4j if a log4j implementation is present, but log4j is not present.
Q5. Looking at the mitigation instructions, we just need to remove those jars from the kc.war. So does this mean that these jars are not required for the WebSphere console to work or it would just disable the logging? We would need to understand the impact or side effects of the jar removals. 
A5. KC.war is used for help embedded in the was admin console. When the jars are removed, trace output is thrown away. So, tracing cannot be used inside this service but it's a service where tracing is almost never used. 
Q6. Should I be alarmed at references to log4j under directories like "properties/patches/backup/9.0.5.3-WS-WASProd-IFPH42728"?
A6. No, these libraries are not loaded by any process. They are stored in this location for rollback (interim fix uninstall) purposes. Deleting the properties/patches/backup/ content of a given interim fix will prevent the successful rollback of that fix. The content will be removed when 8.5.5.21/9.0.5.11 (and later) fix packs are installed. Note: This entry was misleading prior to March 25 2022.
Q7. Should I be alarmed at references to log4j.properties?
A7. No, properties files do not contain executable code. No remediation is required.
Q8. How do I determine if I have installed kc.war
A8. To determine if you have installed kc.war log on systems with grep run the following command from the DMGR profile root, standalone profile root, or WebSphere Base installation root:
               
grep -r com.ibm.kc.ui.UIRootServlet config/ | grep -v isclite
for windows systems without grep, run this command
findstr /s com.ibm.kc.ui.UIRootServlet config\* | findstr /v isclite
If you see no output you do not have kc.war installed. For each instance of the application installed you will see 4 lines. In the example below there is one instance of the kc.war installed in an application called kc_war, uninstall any matching applications via the admin console:
config/cells/staidest1Cell01/applications/kc_war.ear/deployments/kc_war/kc.war/WEB-INF/web.xml:        <servlet-class>com.ibm.kc.ui.UIRootServlet</servlet-class>
config/cells/staidest1Cell01/applications/kc_war.ear/deployments/kc_war/kc.war/WEB-INF/web.xml:            <servlet-class>com.ibm.kc.ui.UIRootServlet</servlet-class>
config/cells/staidest1Cell01/applications/kc_war.ear/deployments/kc_war/kc.war/WEB-INF/ibm-metadata.xml:  <annotated-classes name="com.ibm.kc.ui.UIRootServlet"/>
config/cells/staidest1Cell01/applications/kc_war.ear/deployments/kc_war/kc.war/WEB-INF/web_merged.xml:        <servlet-class>com.ibm.kc.ui.UIRootServlet</servlet-class>
      
Q9. The latest security bulletin has a fix for Liberty, but I thought Liberty wasn't affected by Log4Shell (CVE-2021-44228), was the previous advice incorrect?
A9. Liberty does not include log4j2 and therefore is not vulnerable to Log4Shell. However two optional, rarely used, features on Liberty for z/OS included log4j version 1 for which CVE-2021-4104 was recently released. As an abundance of caution IBM has decided to remove the log4j version 1 usage from these features. These features are zosConnect-1.0 and zosConnect-1.2 and log4j is only used if the configuration element fileSystemloggerInterceptor is present in the server.xml file.
Q10. What does the fix PH42762 do?
A10. The fix removes log4j from the WebSphere traditional admin console and UDDI.ear application. As stated in the bulletin the UDDI application will need to be redeployed to ensure log4j is removed. For Liberty log4j version 1 is also remove for more detail see Q10 above.
Q11. Should I just install PH42762 on the server where dmgr resides, or on appserver nodes too?
A11. IBM recommends installing the interim fix on every WebSphere Application Server Installation.  IBM recommends prioritizing systems to be patched by installing on systems that run the WebSphere Application Server Administration Console, such as a deployment manager or standalone server and systems that run the UDDI Registry application ahead of other systems
Q12. I am running WebSphere traditional in containers, what action should I take to get PH42762?
A12. The WebSphere traditional containers in docker hub have been updated with PH42762 already applied. If using docker build or podman build to build your container set the --pull option. Other tools will have an equivalent, it maybe expressed as a pull policy of always.
Q13. What changes I should expect in my traditional WAS install after applying PH42762?
A13. All versions deliver a new version of uddi.ear which will be in the installableApps directory. For WAS v9 in addition the following files will be changed:
Deleted (v9 only):
WAS_HOME\systemApps\isclite.ear\kc.war\WEB-INF\lib\log4j-1.2-api-2.8.2.jar
WAS_HOME\systemApps\isclite.ear\kc.war\WEB-INF\lib\log4j-api-2.8.2.jar
WAS_HOME\systemApps\isclite.ear\kc.war\WEB-INF\lib\log4j-core-2.8.2.jar
WAS_HOME\systemApps\isclite.ear\kc.war\WEB-INF\lib\log4j-slf4j-impl-2.8.2.jar
Added (v9 only):
WAS_HOME\systemApps\isclite.ear\kc.war\WEB-INF\lib\slf4j-jdk14-1.7.7.jar
Q14. What changes I should expect in my traditional WAS install after applying PH42728 (without also installing PH42762)?
A14. All versions deliver a new version of uddi.ear which will be in the installableApps directory. For WAS v9 in addition the following files will be changed:
Deleted (v9 only):
WAS_HOME\systemApps\isclite.ear\kc.war\WEB-INF\lib\log4j-1.2-api-2.8.2.jar
WAS_HOME\systemApps\isclite.ear\kc.war\WEB-INF\lib\log4j-api-2.8.2.jar
WAS_HOME\systemApps\isclite.ear\kc.war\WEB-INF\lib\log4j-core-2.8.2.jar
WAS_HOME\systemApps\isclite.ear\kc.war\WEB-INF\lib\log4j-slf4j-impl-2.8.2.jar
Added (v9 only):
WAS_HOME\systemApps\isclite.ear\kc.war\WEB-INF\lib\log4j-1.2-api-2.15.0.jar
WAS_HOME\systemApps\isclite.ear\kc.war\WEB-INF\lib\log4j-api-2.15.0.jar
WAS_HOME\systemApps\isclite.ear\kc.war\WEB-INF\lib\log4j-core-2.15.0.jar
WAS_HOME\systemApps\isclite.ear\kc.war\WEB-INF\lib\log4j-slf4j-impl-2.15.0.jar
Q15: What should I do if a filesystem scanner reports an issue in EventCatalogEjb.jar?
A15: This is a false positive due to the presence of a class named "JndiLookup". The class has been reviewed and is not related to log4j and has no known vulnerabilies. No action is required. (Added December 21)
Q16: What about CVE-2021-45105 ?
Q16: CVE-2021-45105 affects the log4j library, but was disclosed subsequent to the publication of PH42762. The log4j library is removed by installing the iFix for PH42762, therefore environments with the iFix or mitigation for PH42762 installed are not vulnerable to CVE-2021-45105. (Added December 21)
Q17: What about CVE-2021-44832 ?
Q17: CVE-2021-44832 affects the log4j library, but was disclosed subsequent to the publication of PH42762. The log4j library is removed by installing the iFix for PH42762, therefore environments with the iFix or mitigation for PH42762 installed are not vulnerable to CVE-2021-44832. (Added January 4 2022)
Frequently Asked Questions for protecting applications deployed to WebSphere (CVE-2021-44228)
Q1. Does WebSphere Application Server have any features that can protect my application use against Log4Shell (CVE-2021-44228) and CVE-2021-45046?
A1. Given the severe nature of this vulnerability IBM has produced a patch for WebSphere traditional and Liberty that will block the loading of the org.apache.logging.log4j.core.lookup.JndiLookup class from the application classloaders. This is not a complete solution but may provide customers with another layer of protection while they remediate their applications. The fix is available via PH42759 (note, the fixes for WebSphere traditional are supplied by interim fix PH42899 which superseded the initial release of PH42759. The original fixes in PH42759 could cause an error for some user of slf4j.  The applicable PH42759 downloads are redirected automatically.). Note: These are not intended as a substitute for the fixes in the security bulletins.
Q2. Does IBM Java default "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to false like Oracle Java?
A2. Yes, IBM Java 8.0.5.25, 7.1.4.35 and 7.0.10.35 and newer behave in this way. However while this blocks the ability to inject running code into a vulnerable system, it does not prevent complex gadget based attacks exploiting other vulnerabilities in code already present. It also does not prevent the data exfiltration possibilities of the Log4Shell. While this mitigates the risk of Log4Shell, it does not remove it, and it does not mitigate CVE-2021-4104 or CVE-2021-45046 and IBM recommends applying PH42728 and updating any use of log4j2 in applications that maybe installed. 

Q3. If I am running with latest version of Java, am i protected? Do i still need to follow remediate steps? 
A3. Log4Shell (CVE-2021-44228) is a vulnerability in the log4j2 open source project. Features in the most recent releases of Java mitigate some, but not all of the risk introduced by the Log4Shell vulnerability. IBM recommends applying PH42762, ensuring Java is at a recent release version above 8.0.5.25, 7.1.4.35 or 7.0.10.35, and customers update any use of log4j2 in applications that maybe installed.

Q4. It will take a long time to update all our applications is there anything we can do to mitigate in the meantime?
A4. Provided log4j 2.10 or newer is being used setting the Java System property  log4j2.formatMsgNoLookups to true will mitigate the Log4Shell vulnerability, but it will not protect against CVE-2021-4104 or CVE-2021-45046. It should be noted that Log4Shell is CVSS 10 and the others require non-default configuration of log4j.
Q5. How can I configure WebSphere traditional with log4j2.formatMsgNoLookups?
A5. Note: Later information from the log4j team describes this mitigation as "insufficient".

The following wsadmin script will update servers to have log4j2.formatMsgNoLookups set. To run this script place it in a file called setlog4jnolookup.py and run the script using bin/wsadmin -f setlog4jnolookup.py. The script will update all JVM's managed by a deployment manager if run against the deployment manager process. If servers are not managed by the deployment manager the script will need to be run against all servers individually. Once the script has exited all the servers will need to be restarted for it to take effect. 
processes = AdminConfig.list("JavaVirtualMachine").splitlines();

for proc in processes:
    AdminConfig.create("Property", proc, [["name","log4j2.formatMsgNoLookups"],["value", "true"]], "systemProperties")

AdminConfig.save()
Q6. How can I configure Liberty with log4j2.formatMsgNoLookups?
A6. Note: Later information from the log4j team describes this mitigation as "insufficient".
Create a jvm.options file in ${wlp.user.dir}/shared/jvm.options with -Dlog4j2.formatMsgNoLookups=true on a line by itself. Then restart all servers for it to take effect. This will apply to all servers in that user dir.

Q7. We are still running our own applications on Java 7 that use log4j2,  but the fixed version of log4j2 requires Java 8
A7. The Apache Logging project released 2.12.2 which supports Java 7, upgrade to this version or a newer 3rd digit release. 

Q8. I cannot find org/apache/logging/log4j/core/lookup/JndiLookup.class in my log4j jar, am I vulnerable to Log4Shell?
A8. It is unlikely you are vulnerable. Most likely you are running log4j1 which is not vulnerable, however you will be vulnerable to CVE-2021-4104.

Q9. If I set log4j2.formatMsgNoLookups to true will it affect my application use of log4j2?
A9. Note: Later information from the log4j team describes this mitigation as "insufficient".
Yes, that will be visible to any and all copies of log4j2 that are in the JVM. This setting is not sufficient to protect against CVE-2021-45046.

Q10. Could setting log4j2.formatMsgNoLookups=true have an effect on log4j 1.x or other non-log4j applications? Is it safe to set this parameter until we have checked every custom written part in our WAS environments? 
A10. Note: Later information from the log4j team describes this mitigation as "insufficient".
The setting should have no affect on non-log4j or log4j 1.x. It is a property related to log4j 2.x behavior. It also does not protect against CVE-2021-45046
Q11. Is IBM Java affected by this vulnerability?
A11. IBM Java does not include the affected library, so it is not directly affected by this vulnerability. However, applications running on top of IBM Java may include vulnerable copies of the affected library and need their own remediation.
List of IBM Application Platform products and components not affected by CVE-2021-44228 and CVE-2021-45046
  • WebSphere Liberty
  • WebSphere Application Server Application Client
  • IBM Installation Manager
  • IBM SDK for Java
  • IBM Semeru Runtimes
  • IBM Mobile First Foundation
  • IBM HTTP Server
  • IBM WebSphere Application Server for IBM Cloud Private VM Quickstarter
  • WebSphere eXtreme Scale
  • IBM WebSphere Application Server Migration Toolkit
  • Open Liberty
  • Liberty for Java (IBM Cloud)
  • Mono2Micro
  • IBM Reactive Platform
  • WebSphere Application Server Developer Tools for Eclipse
  • Liberty Developer Tools
  • WebServer Plugins
  • Edge components
Frequently asked Questions on the WebSphere Application Server Bulletin on Log4Shell (CVE-2021-44228)
 
Note: Interpret this section with caution, it was written prior to the disclosure of CVE-2021-4104 and CVE-2021-45046.
Q1. Is WebSphere Application Server traditional affected by this vulnerability?
A1. Yes please refer to this security bulletin for details on how to apply the fix. However the fixes for this issue are superseded by the fixes in the preceding section for CVE-2021-4104 and CVE-2021-45046

Q2. The Security Bulletin for WebSphere Application Server doesn't mention Liberty, is Liberty affected?
A2. Liberty does not include a copy of log4j2. Note: This is regarding CVE-2021-44228 only.

Q3. I've installed PH42728 on my WebSphere Application Server 8.5.5 system, but the UDDI.ear still contains log4j 2.12.1, am I vulnerable?
A3. No, WebSphere 8.5.5 still supports Java 7 so the 2.15.0 release from Apache cannot be used. IBM has produced a patched version of 2.12.1 which does not contain the vulnerable code.
Q4. Do I have to install PH42728 on all servers, or can I just install it on servers that have the admin console or UDDI?
A4. PH42728 only needs to be installed on servers that have an admin console like a single unmanaged server, or a deployment manager. UDDI runs as an enterprise application so after applying PH42728 onto a server you can use the UDDI.ear to redeploy the UDDI application in any server that runs it.
Q5. I do not have the UDDI application installed do I need to install the iFix?
A5. If running WebSphere traditional 9.0 the iFix is required to remediate other product use of log4j2. If you are running 8.5.5, neglecting to install the iFix will leave a vulnerable library within the UDDI.ear in installableApps.
Q6. I've installed PH42728 does that mean my applications are no longer vulnerable?
A6. PH42728 only fixes the log4j2 used by the admin console and UDDI. If your applications make use of log4j2 they may still be vulnerable. 

Q7. We have noticed that Installation Manager contains ant-apache-log4.jar how can we remediate this? File path is: plugins/org.apache.ant_1.9.6.v201510161327/lib/ant-apache-log4j.jar
A7. It doesn't require remediation. This jar does not contain log4j at any version. It includes code to use log4j if a log4j implementation is present, but not log4j is present.
Q8. Looking at the mitigation instructions, we just need to remove those jars from the kc.war. So does this mean that these jars are not required for the WebSphere console to work or it would just disable the logging? We would need to understand the impact or side effects of the jar removals. 
A8. KC.war is used for help embedded in the was admin console. When the jars are removed, trace output is thrown away. So, tracing cannot be used inside this service but it's a service where tracing is almost never used. 
Q9. How do I determine if I have installed kc.war
A9. To determine if you have installed kc.war log run the following command from the DMGR profile root, standalone profile root, or WebSphere Base installation root:
               
grep -r com.ibm.kc.ui.UIRootServlet config/ | grep -v isclite
If you see no output you do not have kc.war installed. For each instance of the application installed you will see 4 lines. In the example below there is one instance of the kc.war installed in an application called kc_war, uninstall any matching applications via the admin console: 
config/cells/staidest1Cell01/applications/kc_war.ear/deployments/kc_war/kc.war/WEB-INF/web.xml:        <servlet-class>com.ibm.kc.ui.UIRootServlet</servlet-class>
config/cells/staidest1Cell01/applications/kc_war.ear/deployments/kc_war/kc.war/WEB-INF/web.xml:            <servlet-class>com.ibm.kc.ui.UIRootServlet</servlet-class>
config/cells/staidest1Cell01/applications/kc_war.ear/deployments/kc_war/kc.war/WEB-INF/ibm-metadata.xml:  <annotated-classes name="com.ibm.kc.ui.UIRootServlet"/>
config/cells/staidest1Cell01/applications/kc_war.ear/deployments/kc_war/kc.war/WEB-INF/web_merged.xml:        <servlet-class>com.ibm.kc.ui.UIRootServlet</servlet-class>
       
Q10. Should I be alarmed at references to log4j under directories like "properties/patches/backup/9.0.5.3-WS-WASProd-IFPH42728" ?
A10. No, these libraries are not loaded by any process. They are stored in this location for rollback purposes.
Q11. Should I be alarmed at references to log4j.properties?
A11. No, properties files do not contain executable code. No remediation is required.
Q12. What about IBM HTTP Server, the WebServer Plugins, or Edge components of Network Deployment like Caching Proxy and Load Balancers?
A12. These separately installable components do not include any copy of log4j and are not affected by this CVE.
Q13. I am running WebSphere traditional in containers, what action should I take to get PH42728?
A13. The WebSphere traditional containers in docker hub have been updated with PH42728 already applied. If using docker build or podman build to build your container set the --pull option. Other tools will have an equivalent, it maybe expressed as a pull policy of always.

[{"Type":"MASTER","Line of Business":{"code":"LOB45","label":"Automation"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"ARM Category":[{"code":"a8m0z0000001gI0AAI","label":"IBM WebSphere Liberty-All Platforms-\u003ELiberty Profile-\u003ELiberty Security"},{"code":"a8m50000000CcxxAAC","label":"WebSphere Application Server traditional-All Platforms-\u003ESecurity"}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"},{"Type":"MASTER","Line of Business":{"code":"LOB45","label":"Automation"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SS7JFU","label":"WebSphere Application Server - Express"},"ARM Category":[{"code":"a8m0z0000001gI0AAI","label":"IBM WebSphere Liberty-All Platforms-\u003ELiberty Profile-\u003ELiberty Security"},{"code":"a8m0z000000bmldAAA","label":"WebSphere Application Server traditional-All Platforms-\u003ESecurity-\u003EVulnerabilities"}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"},{"Type":"MASTER","Line of Business":{"code":"LOB45","label":"Automation"},"Business Unit":{"code":"BU053","label":"Cloud \u0026 Data Platform"},"Product":{"code":"SUNSET","label":"PRODUCT REMOVED"},"ARM Category":[{"code":"a8m0z0000001gI0AAI","label":"IBM WebSphere Liberty-All Platforms-\u003ELiberty Profile-\u003ELiberty Security"},{"code":"a8m0z000000bmldAAA","label":"WebSphere Application Server traditional-All Platforms-\u003ESecurity-\u003EVulnerabilities"}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"},{"Type":"MASTER","Line of Business":{"code":"LOB45","label":"Automation"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSAW57","label":"WebSphere Application Server Network Deployment"},"ARM Category":[{"code":"a8m0z0000001gI0AAI","label":"IBM WebSphere Liberty-All Platforms-\u003ELiberty Profile-\u003ELiberty Security"},{"code":"a8m0z000000bmldAAA","label":"WebSphere Application Server traditional-All Platforms-\u003ESecurity-\u003EVulnerabilities"}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"},{"Type":"MASTER","Line of Business":{"code":"LOB45","label":"Automation"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSD28V","label":"WebSphere Application Server Liberty Core"},"ARM Category":[{"code":"a8m0z0000001gI0AAI","label":"IBM WebSphere Liberty-All Platforms-\u003ELiberty Profile-\u003ELiberty Security"},{"code":"a8m0z000000bmldAAA","label":"WebSphere Application Server traditional-All Platforms-\u003ESecurity-\u003EVulnerabilities"}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]

Document Information

Modified date:
25 March 2022

UID

ibm16525860

Page Feedback