KB Article #181923
Impact and resolution of CVE-2021-44228 (Log4Shell) in B2Bi, Activator, Integrator, Interchange and MappingServices
Context
A 0-day vulnerability in the popular Java logging library, log4j, was published on GitHub along with a POC that shows the possibility of Remote Code Execution (RCE) if log4j logs an attacker-controlled string value, CVE-2021-44228.
Axway is aware of Log4j CVE-2021-44228 and is evaluating its impact on all Axway products. As conclusions and recommendations are available we will be publishing them in the dedicated Alert on support.axway.com: https://support.axway.com/news/1331/lang/en
The current article intends to provide recommendations and technical clarifications with regards to the impact of CVE-2021-44228 in B2Bi, Activator, Integrator, Interchange and MappingServices.
Permanent Solution
Permanent solution: Use log4j version 2.17.1 or higher. All supported product versions potentially impacted by CVE-2021-44228 will issue updates to include log4j 2.17.1 or higher.
For all B2Bi 2.6 UP2021-11 users the recommendation is to apply B2Bi 2.6 UP2021-11 P1.
For all B2Bi users with versions lower than 2.6 UP2021-11 the recommendation is to update to B2Bi 2.6 UP2021-11 P1, otherwise the below mitigation steps have to to be considered.
Mitigation
Important
As of 12/18/2021 a new vulnerability has been exposed in all log4j 2.x <= 2.16 (CVE-2021-45105). None of the products and versions listed in this section are impacted by this issues as the do not use Context Lookups as part of the log4j configuration
Product | Product Version(s) | Log4j Version(s) | Impact | Mitigation |
---|---|---|---|---|
B2Bi | 2.6 UP2021-11 | log4j >= 2.12.0 | Possible impact | The resolution is to delete the JndiLookup.class from all relevant jars in the B2Bi installation. Please refer to the Log4j2 Mitigation Steps section below. Secure Relay Integration: If B2Bi is integrated with Secure Relay, the steps performed for B2Bi installation address the issue for new Secure Relay DMZ nodes that will be exported from the B2Bi UI in the future (because the vulnerable classes are removed from B2BI_INSTALL/Interchange/util/dmzNode/xsr/lib/log4j*.jar libraries). For all existing Secure Relay Router Agent nodes already running and used by B2Bi, after applying the steps for B2Bi installation, you need to:
B2Bi Client/Mapping Services:
B2Bi Multi-Cluster:
|
B2Bi | 2.6 UP2021-04 2.6 UP2021-02 2.6 SP2 | log4j >= 2.12.0 log4j 1.x | Possible impact | The same mitigation steps as for the latest version (2.6 UP2021-11) apply. For log4j1 please refer to the Log4j1 Mitigation Steps below. |
2.4.0 | log4j 2.8.2 log4j 1.x | Possible impact | Same as for 2.6 SP2 | |
2.3.1 | log4j 2.8.2 log4j 1.x | Possible impact | Same as for 2.6 SP2 | |
2.2.1 <= | log4j 1.x | Not vulnerable | Please refer to Log4j1 Mitigation Steps below. | |
Activator | 6.1 UP2021-07 | log4j 2.13.0 | Possible impact | Apply the Activator 6.1 UP2021-07 Log4j2 Hotfix present on the Axway Support Website. |
Activator | 6.1 | log4j 2.8.2 | Possible impact | Apply the Activator 6.1 Log4j2 Hotfix present on the Axway Support Website. |
Activator | 6.0 | log4j 2.8.2 | Possible impact | The solution is to remove org/apache/logging/log4j/core/lookup/JndiLookup.class and org/apache/logging/log4j/core/net/JndiManager.class from the jar Activator/corelib/log4j-core*.jar |
Mapping Services | 3.6 UP2021-11 | log4j 2.14.0 log4j 2.0-rc1 log4j 1.x | Possible impact |
For log4j1 please refer to Log4j1 Mitigation Steps below. |
Mapping Services | < 3.6 UP2021-11 | log4j 2.0-rc1 log4j 1.x | Not vulnerable | Replace the file <repositoryLocation>/hooks/functions/log4j-core-2.0-rc1.jar of each repository with the utility available on the support site (Utility_log4j2_MappingServices_allOS_BN1.jar) but keep the same name (log4j-core-2.0-rc1.jar), and then restart your SVN server. For log4j1 please refer to Log4j1 Mitigation Steps below. |
Integrator | 3.7.3 | log4j 1.x | Not vulnerable | Please refer to Log4j1 Mitigation Steps below. |
Integrator | 2.2.1 | log4j 1.x | Not vulnerable | Please refer to Log4j1 Mitigation Steps below. |
Interchange/ Activator | 5.12.0 | log4j 1.x | Not vulnerable | Please refer to Log4j1 Mitigation Steps below. |
Log4j2 Mitigation Steps
Note
This section details how to Remove JndiLookup.class in B2Bi. Eliminating the class JndiLookup.class from all log4j-*core*.jar files will mitigate the issue.
Warning
If any service pack or upgrade pack is applied the procedure needs to be redone. This is valid also for new product installations.
Prerequisites
- Linux: zip and unzip linux commands need to be available.
- Windows: 7Zip available (or equivalent WinZip, Winrar,….etc) or Powershell
B2Bi on Redhat/Suse/CentOS
The script Log4jv2 Utility (linux-x86-64) - available on support site - can be used to fix all impacted .jar files in a folder.
Run the script with parameter FIX in B2Bi root folder and in all folders outside of the B2Bi which might contain jar files added to the classpath.
Example:
cd Axway
#
|
B2Bi on other Linux/Unix distributions
Step 1: Go in B2Bi root folder (the folder that contains Integrator and Interchange)
cd <path to> /Axway |
Step 2: Find all log4j-core jar files in current folder using a command like:
find . -iname 'log4j-*core*.jar' |
Step 3: For each .jar file reported at previous step use zip program to remove class JndiLookup.class and JndiManager.class
|
Step 4: For each .jar file reported at previous step verify if the class was removed properly
|
Step 5: Repeat the above process for each folder and for each log4j-core*.jar file that was added manually in classpath from outside standard folders, due to some customizations. Some customers may add .jar files in some subfolders from share folder.
B2Bi on Windows using Using PowerShell
The script Log4jv2 Utility (win-x86-64) - available on support site - can be used to fix all impacted .jar files in a folder.
Run the script with parameter FIX in B2Bi root folder and in all folders outside of the B2Bi which might contain jar files added to the classpath.
Step 1: Start PowerShell
Step 2: Go to your B2Bi installation root folder
cd <path to> /Axway |
Step 3: Run the script with parameter FIX in B2Bi root folder and in all folders outside of the B2Bi which might contain jar files added to the classpath.
Usage:
Utility_log4jv2_win-x86-64_BNx.ps1 ANALYZE|FIX [ -backupFolder <BACKUP_FOLDER> ] |
Notes:
- Perform ANALYZE first, then FIX, then check it with ANALYZE again, you should see all the impacted jars are now reported as OK.
- If an error that the that the script is not digitally signed and won't execute on the system appears, run the following command in the open PowerShell session:
This will only affect the current session and will be discarded on closing the PowerShell window.Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
- After the class is eliminated from jar files some warning may appear in some log files like:
WARN JNDI lookup class is not available because this JRE does not support JNDI. JNDI string lookups will not be available, continuing configuration. Ignoring java.lang.ClassNotFoundException: org.apache.logging.log4j.core.lookup.JndiLookup |
B2Bi on Windows with manual steps
Step 1: Go in B2Bi root folder (the folder that contains Integrator and Interchange)
cd <path to>\Axway |
Step 2: Find all log4j-core jar files using a command like:
dir /b /s log4j-*core*.jar |
Step 3: For each log4j-core file open the jar file in a zip manager tool(like 7Zip) and remove classes org/apache/logging/log4j/core/lookup/JndiLookup.class and org/apache/logging/log4j/core/net/JndiManager.class
Note
After the class is eliminated from jar files some warning may appear in some log files like:
WARN JNDI lookup class is not available because this JRE does not support JNDI. JNDI string lookups will not be available, continuing configuration. Ignoring java.lang.ClassNotFoundException: org.apache.logging.log4j.core.lookup.JndiLookup |
Log4j1 Mitigation Steps
Log4j v1.x and is not impacted by the attack vector described in CVE-2021-44228 nor by the pre-existing vectors related to SocketServer and JmsAppender (CVE-2019-17571, CVE-2021-4104).
As an extraordinary precaution for log4j 1.x we recommend that you review all log4j configuration files and remove or comment out any reference to:
org.apache.log4j.net.JMSAppender
org.apache.log4j.net.SocketServer
org.apache.log4j.net.SocketAppender
org.apache.log4j.net.SocketHubAppender
org.apache.log4j.net.SimpleSocketServer
For CVE-2022-23302 review all log4j configuration files and remove or comment out any reference to JMSSink.
For CVE-2022-23305 review all log4j configuration files and remove or comment out any reference to JDBCAppender.
For CVE-2022-23307 avoid using Chainsaw to view logs, and instead use some other utility, especially if there is a log view available within the product itself.
Warning
If any service pack or upgrade pack is applied the procedure needs to be redone. This is valid also for new product installations.
Prerequisites
- Linux: zip and unzip linux commands need to be available.
- Windows: 7Zip available (or equivalent WinZip, Winrar,….etc) or Powershell
Steps to Perform
Step1: Find all files named log4j.jar or log4j-1.*.jar excluding log4j-1.2-api-*.jar (which is part of log4j2):
Linux:
find . -iname 'log4j-1.*.jar' -o -iname 'log4j.jar' | grep -v '/log4j-1.2-api[\.-]'
or Windows (command line):
dir /b /s log4j-1*.jar | findstr /V "log4j-1.2-api-*" & dir /b /s log4j.jar
Step 2: Remove the classes listed below from the jars found at the step above:
org.apache.log4j.net.JMSAppender
org.apache.log4j.net.SocketServer
org.apache.log4j.net.SocketAppender
org.apache.log4j.net.SocketHubAppender
org.apache.log4j.net.SimpleSocketServer
org.apache.log4j.net.JMSSink
org.apache.log4j.jdbc.JDBCAppender
org.apache.log4j.chainsaw.*
Examples (Linux or Windows Powershell):
zip -q -d <log4j_v1_file> org/apache/log4j/net/JMSAppender.class
zip -q -d <log4j_v1_file> org/apache/log4j/chainsaw/*
For Windows without Powershell you can use 7zip or similar.
Step 3: Repeat the above process for each folder and for each jar file matching the search criteria that was added manually in classpath from outside standard folders, due to some customizations. Some customers may add .jar files in some subfolders from share folder.