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 Gateway

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.

For all platforms except for sun-sparc-32, version 6.17.3 SP10:

• Secure Relay MA, embedded in Gateway, is using log4j 2.14.
• JMS Connector and SWIFT user exit use log4j 2.10.
• These are run on Java 8 U275.

For sun-sparc-32 and for all platforms if version 6.17.3 is lower than SP10:

• Secure Relay MA, embedded in Gateway, is using log4j 1.x.
• JMS Connector and SWIFT user exit use log4j 2.10.

For older versions, now EOS or superseded by newer minor versions, ex. 6.16.1 or 6.17.2:

• Log4j 1.x for all areas

In log4j1 the code reported as vulnerable by CVE-2021-44228 is not present, but we have updated information that log4j1 can be vulnerable related to other CVEs. For now these have been confirmed: https://nvd.nist.gov/vuln/detail/CVE-2019-17571 and https://access.redhat.com/security/cve/CVE-2021-4104. Therefore, we recommend removing the vulnerable classes from log4j libraries.

Resolution

Permanent Solution

We are closely monitoring the situation regarding log4j vulnerabilities and advise you to check the KB for updates weekly.

If new issues are being discovered, actions will be taken according to the associated severity of the vulnerability, starting with the assessment of how/if the product is affected.

In case of critical or high vulnerability (CVSS score 7.0 or higher), immediate action will be taken: mitigation will be offered or a Patch will be planned.

If newer log4j versions are released after 2.17, containing additional security fixes, the next Service Pack will include the latest available around delivery time.

As of December 23, 2021, Gateway 6.17.3 SP10 Patch2 was published for all platforms, delivering:

For all platforms except sun-sparc-32:

• log4j 2.17 for JMS Connector and SWIFT user exit use
• log4j 2.16 for Secure Relay MA

For sun-sparc-32:

• log4j 2.12.3 for JMS Connector and SWIFT user exit use. This log4j version provides the security fixes at 2.17 level, but for Java 7 (Gateway runs on Java 7 on sun-sparc platform)
• for Secure Relay MA, log4j v1 is kept.

Note: If this permanent solution is applied, then the only mitigation that still needs to be applied is regarding the log4j v1 usage for Secure Relay MA when on sun-sparc-32.

Mitigations

Prerequisites

• Linux: zip and unzip Linux commands need to be available.
• Windows: 7Zip available (or equivalent WinZip, Winrar,….etc)

Important notes

• If any service pack or upgrade pack is applied the procedure needs to be redone. This is valid also for new product installations.
• Please backup all the files to be modified. It is mandatory to backup them in a place outside the installation.

LINUX/UNIX

Step 1: Stop Gateway

Step 2: Go in Gateway installation folder

cd <install_dir>/Gateway

NOTE: You need to perform Step 3, 4 and 5 if using 6.17.3 version, any Service Pack level.

Step 3: Find all log4j-core v2 jar files in current folder using a command like:

find . -name 'log4j-*core*.jar'

Account only the ones found in /bin/xsr/ and /run_time/jms folders. You can encounter jar files also in the /synInstall folder, but there is no need to change them.

Step 4: Remove vulnerable classes from log4j v2.

For each .jar file reported at the previous step use zip program to remove class JndiLookup.class and JndiManager.class

Step 5: For each .jar file reported at previous step, verify if the classes were removed properly

NOTE: You need to perform Step 6, 7 and 8 if you are on:

• platform sun-sparc-32 with 6.17.3 version, any Service Pack level
• any other platform with 6.17.3 SP9 or lower
• versions of Gateway older than 6.17.3

Step 6: Find all log4j v1 jar files in current folder using a command like:

find . -name 'log4j-1.2.*.jar'

Account only the ones found in /bin/xsr/. There is a jar file called log4j-1.2.16.jar also in /run_time/jms folder but it is unused, it can be simply removed. You can encounter jar files also in the /synInstall folder, but there is no need to change them.

Step 7: Remove vulnerable classes from log4j v1.

For each .jar file reported at the previous step use zip program to remove following vulnerable classes:

Step 8: For each .jar file reported at previous step verify if the classes were removed properly

Step 9: Start Gateway

WINDOWS

Step 1: Stop Gateway

Step 2: Go in Gateway installation folder

cd <install_dir>/Gateway

NOTE: You need to perform Step 3 and Step 4 if using 6.17.3 version, any Service Pack level.

Step 3: Find all log4j-core v2 jar files in current folder, for example by using a command like:

dir /b /s log4j-*core*.jar

Account only the ones found in /bin/xsr/ and /run_time/jms folders. You can encounter jar files also in the /synInstall folder, but there is no need to change them.

Step 4: Remove vulnerable classes from log4j v2.

For each log4j-core file reported at previous step open the jar file in a zip manager tool(like 7Zip) and remove classes:

• org/apache/logging/log4j/core/lookup/JndiLookup.class
• org/apache/logging/log4j/core/net/JndiManager.class

NOTE: You need to perform Step 5 and Step 6 if you are on:

• platform sun-sparc-32 with 6.17.3 version, any Service Pack level
• any other platform with 6.17.3 SP9 or lower
• versions of Gateway older than 6.17.3

Step 5: Find all log4j-core v1 jar files in current folder, for example by using a command like:

dir /b /s log4j-1.2.*.jar

Account only the ones found in /bin/xsr/. There is a jar file called log4j-1.2.16.jar also in /run_time/jms folder but it is unused, it can be simply removed. You can encounter jar files also in the /synInstall folder, but there is no need to change them.

Step 6: Remove vulnerable classes from log4j v1.

For each log4j file reported at previous step open the jar file in a zip manager tool(like 7Zip) and remove classes:

• org/apache/log4j/net/SocketServer.class
• org/apache/log4j/net/SocketAppender.class
• org/apache/log4j/net/SocketHubAppender.class
• org/apache/log4j/net/SimpleSocketServer.class
• org/apache/log4j/net/JMSAppender.class

Step 7: Start Gateway