KB Article #181921
SECURITY: Impact and resolution of CVE-2021-44228 (Log4Shell) in SecureTransport
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.
The current article intends to provide recommendations and technical clarifications with regards to the impact of CVE-2021-44228 in SecureTransport.
Resolution
Impacted Products
The impact derives from the use of Apache log4j within the products and all log4j versions between and including 2.0 and 2.14.1 are impacted. Some variations in impact exist based on the exact log4j and JRE version.
| ST | Log4J | JRE | Impact | Solutions |
| 5.5 | v2.14.0 | Open JDK 11.0.12+7 (Post ST 5.5 August Update) | Partially no. Possible impact exist. | The ST 5.5 December 2021 Update upgrades the log4j to the non-vulnerable v2.16.0. ST 5.5 January Update will introduce log4j 2.17.1 The mitigation solution exists and we recommend it is applied for versions older than the December 2021 update: Mitigation for Log4j v2 Mitigation for Log4j v1 Mitigation using Axway-provided scripts |
| 5.4 with latest GA Patch (P45)
EOS date: 31.05.2022 |
v1.2.16 | Oracle JDK 1.8.0-281 | No.
The code reported as vulnerable in log4j2 is not present in log4j1. By default ST does not use JMSAppender nor SocketServer Appender (which were reported as vulnerable in log4j1). |
At the moment, there is no evidence to show that ST 5.4 is vulnerable to CVE-2021-44228.
In addition, the code reported as vulnerable is not present. The mitigation solution exists and we recommend it is applied: Mitigation for Log4j v1 Mitigation using Axway-provided scripts |
| 5.3.6 (latest patch) EOS date: 12.12.2021 |
v1.2.16 | Oracle JDK 1.8.241 | No.
The code reported as vulnerable in log4j2 is not present in log4j1. By default ST does not use JMSAppender nor SocketServer Appender (which were reported as vulnerable in log4j1). |
At the moment, there is no evidence to show that ST 5.3.6 is vulnerable by CVE-2021-44228.
In addition, the code reported as vulnerable is not present. The mitigation solution exists and we recommend it is applied: Mitigation for Log4j v1 Mitigation using Axway-provided scripts |
Permanent Solution
Use log4j version 2.15 or higher.
CVE-2021-44228 vulnerability is solved in Log4j version 2.15. Axway released the December 2021 Update for ST 5.5 where Log4j v2 was upgraded to v2.16.0. ST 5.5 January Update will introduce log4j v2.17.1.
For ST 5.5 versions older than the December 2021 Update customers can rely on mitigation options described below.
Mitigation: Preparations
The goal of the mitigation steps is the removal of JndiLookup and JndiManager classes for Log4j v2 and the removal of the SocketServer* and JMSAppender classes for Log4j v1. The changes must be done to both SecureTransport and Axway Installer in each scenario.
Before you begin you need to locate the relevant log4j files, using the following commands:
| Linux | find <INSTALL_PATH>/ -name log4j*.jar |
| Windows | where /r <INSTALL_PATH>\ log4j*.jar |
where INSTALL_PATH should be replaced with SecureTransport's home folder and Axway Installer's home folder.
Mitigation for Log4j v2
Applicable for ST 5.5 December 2020 update (SecureTransport 5.5-20201218) and above. For lower versions, use the steps for Log4j v1 below.
Not applicable for ST 5.5 December 2021 update (SecureTransport 5.5-20211216) and above. The fix is already included in the December 2021 Update for ST 5.5.
For Linux OS
Stop all ST services
Remove the JndiLookup and JndiManager classes, using the following commands:
zip -q -d <LOG4J_PATH>/log4j-core*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class zip -q -d <LOG4J_PATH>/log4j-core*.jar org/apache/logging/log4j/core/net/JndiManager.class
where <LOG4J_PATH> should be replaced with the full system path to the log4j file from the preparations steps described above.
Restart all ST services
If log4j.jar or log4j-VERSION.jar exist, perform the steps for Log4j v1 below.
For Windows OS
Install 7z on the Windows server, where ST runs.
Stop all SecureTransport services.
Open CMD or PowerShell prompt and go to the 7z installation folder.
Remove the JndiLookup and JndiManager classes, using the following commands:
.\7z.exe d <LOG4_PATH>\log4j-core.jar org/apache/logging/log4j/core/lookup/JndiLookup.class .\7z.exe d <LOG4_PATH>\log4j-core.jar org/apache/logging/log4j/core/net/JndiManager.class
where <LOG4J_PATH> should be replaced with the full system path to the log4j file from the preparations steps described above. Repeat these steps for for all log4j-core*.jar files located in SecureTransport's home folder and Axway Installer's home folder.
Restart all ST services
If log4j.jar or log4j-VERSION.jar exist, perform the steps for Log4j v1 below.
Mitigation for Log4j v1
Applicable for versions older than ST 5.5 December 2020 update (SecureTransport 5.5-20201218), including ST 5.4 and ST 5.3.6. For higher versions, use the steps for Log4j v2 above.
For Linux OS
Stop all SecureTransport services.
Remove the SocketServer* and JMSAppender classes, using the following commands:
zip -q -d <LOG4J_PATH>/log4j*.jar org/apache/log4j/net/SocketServer.class zip -q -d <LOG4J_PATH>/log4j*.jar org/apache/log4j/net/SocketAppender.class zip -q -d <LOG4J_PATH>/log4j*.jar org/apache/log4j/net/SocketHubAppender.class zip -q -d <LOG4J_PATH>/log4j*.jar org/apache/log4j/net/SimpleSocketServer.class zip -q -d <LOG4J_PATH>/log4j*.jar org/apache/log4j/net/JMSAppender.class
where <LOG4J_PATH> should be replaced with the full system path to the log4j file from the preparations steps described above. Repeat these steps for for all log4j.jar and log4j-VERSION.jar files located in SecureTransport's home folder and Axway Installer's home folder.
Review all log4j configuration files and remove or comment out any reference to any of the classes below:
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
Restart all ST services
For Windows OS
Install 7z on the Windows server, where ST runs.
Stop all SecureTransport services.
Open CMD or PowerShell prompt and go to the 7z installation folder.
Remove the SocketServer* and JMSAppender classes, using the following commands:
.\7z.exe d <LOG4_PATH>\log4j.jar org/apache/log4j/net/SocketServer.class .\7z.exe d <LOG4_PATH>\log4j.jar org/apache/log4j/net/SocketAppender.class .\7z.exe d <LOG4_PATH>\log4j.jar org/apache/log4j/net/SocketHubAppender.class .\7z.exe d <LOG4_PATH>\log4j.jar org/apache/log4j/net/SimpleSocketServer.class .\7z.exe d <LOG4_PATH>\log4j.jar org/apache/log4j/net/JMSAppender.class
where <LOG4J_PATH> should be replaced with the full system path to the log4j file from the preparations steps described above. Repeat these steps for for all log4j.jar and log4j-VERSION.jar files located in SecureTransport's home folder and Axway Installer's home folder.
Review all log4j configuration files and remove or comment out any reference to any of the classes below:
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
Restart all ST services
Mitigation using Axway-provided scripts
The scripts attached to this article can be used to automate the above steps. The scripts are intended to cover both the Log4j v2 and Log4j v1 cases.
For Linux OS
The log4j_utility_linux.sh script removes the vulnerable classes from the log4j v1 or log4 v2 jar files.
Download the log4j_utility_linux.sh script from this article (top of the right-hand side pane) and place it on the server running ST.
Make sure you are logged in to the server's console with the user that runs ST.
Execute the script like this:
./log4j_utility_linux.sh <INSTALL_PATH> <LOG4J_VERSION>
where
INSTALL_PATH should be replaced with the full system path to the SecureTransport's home folder and Axway Installer's home folder.
LOG4J_VERSION for Log4j v1 use 1; for Log4j v2 use 2.
Restart all ST services
For Windows OS
The log4j_utility_windows.ps1 script removes the vulnerable classes from the log4j v1 or log4 v2 jar files.
Install 7z on the Windows server, where ST runs.
Download the log4j_utility_windows.ps1 script from this article (top of the right-hand side pane) and place it on the server running ST.
Stop all SecureTransport services.
Open PowerShell prompt and go to the script's folder.
Execute the script like this:
.\log4j_utility_windows <INSTALL_PATH> <LOG4J_VERSION> <7z_INSTALL_FOLDER>
where
INSTALL_PATH should be replaced with the full system path to the SecureTransport's home folder and Axway Installer's home folder.
LOG4J_VERSION for Log4j v1 use 1; for Log4j v2 use 2.
7z_INSTALL_FOLDER should be changed with 7z tool's installation folder path.
Restart all ST services