Log4Shell Security Impact Statement

Original publication date:  2021-Dec-14 15:00 EST

Last Update: 2022-APR-05 17:37 EST  This page will be updated continuously as confirmations are received.

This page is to inform TRAX Customers about the applications that have been distributed to Customers that are hosted on TRAXCloud, or self-hosted on-premise or with other 3rd parties.

Here are the answers to the most common questions we’ve received:

Question 1:   Do any Trax applications require or depend on the log4j-core?

Answer:  NO.  In fact none the apps load the log4j-core jar file except TraxDocServices and Interfaces used by several Customers. Regardless, Trax is working to replace the apps that contain log4j 2.x and distributing them with the latest log4j with immediate urgency.

 

Question 2:  Does Trax distribute this file in its applications? 

Answer:   YES! In our Java-based apps & interfaces as follows:

1.  TraxDocServices & EmployeeSchedule Apps, has been identified as containing log4j 2.11.1. The product teams are working on replacing this with log4j-core-2.17.1.jar BUT Customers:

         a. that are hosted on the TRAXCloud will be contacted by TRAX IT to schedule the server restarts required to apply the new war files.

         b. that host on-premise or with other 3rd parties, must submit a Weblog on https://icentral.trax.aero requesting the newly recompiled war file and the Support team will make it available for Customers to download. In the interim, Customers that are running TraxDocServices (and others affected on the list below) on-premise, are encouraged to immediately apply the applicable remedy/upgrade manually as instructed by the Apache security bulletins as it will not affect our applications. Links to the upgrade downloads are at the end of this document. 

2.  Interfaces:  All interface war files contain a version of the log4j files and therefore must be mitigated accordingly as instructed below.

a.  Refer to our documentation in the Technical & Interface Document Library in iCentral, the document How to Set Up Log4j Configuration.pdf explains how to configure log4j to aid in troubleshooting any interface errors when they occur. It has been revised to include a Critical alert to the existence of these CVEs and directs the reader to this statement/page.

4.  Other vendors’ technologies may require mitigation of log4j so it is best to inventory all application servers for the existence of this application in each server and mitigate accordingly. See Wildfly & Jasper Reports Server in the Impact List below.

5.  Trax Maintenance Windows App v5 – v15+ distributes the TraxDoc Module with the JRE in the OCX folder where you will find the log4j 1.x which is not indicated as vulnerable by Apache but your vulnerability scanner may identify it as such. Changing from 1.x to 2.x of log4j calls for a change/modification to the code in order to use the new classes introduced by log4j 2.x which is not being considered at this time in our development roadmap. If your Trax ocx folder contains log4j 2.x you can follow the steps recommended by Apache without issue. If you don’t have log4j 2.x, there is not mitigation steps that can be followed except for 1 exception. If your organization does not import XML/SGML manuals using TraxDoc, you can zip up the log4j files as they are not used nor is Java being used nor is ApacheFOP being used to build the PDF files generated during the Work Pack Print or other processes that take the imported XML/SGML and renders it to PDF format. If you organization simply links E/Cs & Taskcards to an existing library of PDFs that are externally linked to a repository of files, this indicates you are not in need of the Java JRE or the log4j file.

Question 3:  Which mitigation measures does Trax recommend at this time?

Answer: The following list is an outline of the options:

1.  The mitigation of this vulnerability has been changing weekly, just see the History section of the Apache Log4j Security page by visiting https://logging.apache.org/log4j/2.x/security.html and following their Mitigation steps. Follow them immediately where you find v2.x of the log4j file. Then set a reminder to revisit the page every few days to be certain that the mitigation steps you implemented remain effective. OR 

2.  Apply the Java 11 upgrade, it is another way to mitigate the log4j vulnerability. You have to be in the latest versions of eMRO & eMobility. All our JDK deployed applications are certified for JDK 11 deployment so this would be a two-for-one option where you’d mitigate the log4j vulnerability and you advance on the migration to Java JDK v11 that is due by March of 2022.

 

Question 4:  Which are the CVEs to be concerned about for log4j?

Answer: Here are the CVEs that score above 6.0…

CVE-2021-44228 CVSS score of 10.0 rated Critical Impact.

In Apache Log4j2 versions up to and including 2.14.1 (excluding security releases 2.3.1, 2.12.2 and 2.12.3), the JNDI features used in configurations, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI related endpoints.

Log4j 1.x mitigation

Log4j 1.x does not have Lookups so the risk is lower. Applications using Log4j 1.x are only vulnerable to this attack when they use JNDI in their configuration. A separate CVE (CVE-2021-4104) has been filed for this vulnerability. To mitigate: Audit your logging configuration to ensure it has no JMSAppender configured. Log4j 1.x configurations without JMSAppender are not impacted by this vulnerability.

Log4j 2.x mitigation

Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).

 

CVE-2021-45046 CVSS v3 score of 9.0 rated Critical Impact.

It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations.

Log4j 1.x mitigation

Log4j 1.x is not impacted by this vulnerability.

Log4j 2.x mitigation

Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).

 

CVE-2021-44832 CVSS v3 score of 6.6 rated Moderate Impact.

Log4j 1.x mitigation

Log4j 1.x is not impacted by this vulnerability.

This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.

Log4j 2.x mitigation

Upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later).

 

CVE-2021-45105 CVSS Score of 5.9 rated Moderate Impact.

Log4j 1.x mitigation

Log4j 1.x is not impacted by this vulnerability.

Log4j 2.x mitigation

Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).

CVE-2022-23305 is a high severity 8.1 vulnerability. Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default.

A flaw was found in the Java logging library Apache Log4j in version 1.x. JDBCAppender in Log4j 1.x is vulnerable to SQL injection in untrusted data. This allows a remote attacker to run SQL statements in the database if the deployed application is configured to use JDBCAppender with certain interpolation tokens.

Log4j 1.x mitigation

– Comment out or remove JDBCAppender in the Log4j configuration if it is used
– Remove the JDBCAppender class from the server’s jar files. For example:

zip -q -d log4j-*.jar org/apache/log4j/jdbc/JDBCAppender.class

Log4j 2.x mitigation

Log4j 2.x is not impacted by this vulnerability.

Other CVEs:

CVE-2022-23302 is a high severity deserialization vulnerability in JMSSink. JMSSink uses JNDI in an unprotected manner allowing any application using the JMSSink to be vulnerable if it is configured to reference an untrusted site or if the site referenced can be accesseed by the attacker. For example, the attacker can cause remote code execution by manipulating the data in the LDAP store.

CVE-2022-23307 is a high severity 8.1 vulnerability. A flaw was found in the log4j 1.x chainsaw component, where the contents of certain log entries are deserialized and possibly permit code execution. This flaw allows an attacker to send a malicious request with serialized data to the server to be deserialized when the chainsaw component is run.

 

 

Click here to view the TRAX Application & Interface log4j Impact List

For immediate mitigation, download the matching log4j file below and replace the file on all your servers by executing the following cmdline: find /opt/ -type f -name log4j\*jar to identify the vulnerable file/version and replacing it with the latest version from here: /log4j-core

According to Apache, the vulnerability exists only in the LOG4J-CORE jar file. However, if you want to be safe & consistent you should upgrade the other log4j jar files to the latest version for all servers running java apps in your infrastructure. Here are the links to download those files:

          log4j-api-2.XX /log4j-api

          log4j-jcl-2.XX  /log4j-jcl

          log4j-jul-2.XX  /log4j-jul

          log4j-slf4j-impl-2.XX  /log4j-slf4j-impl

          log4j-web-2.XX /log4j-web

          log4j-1.2-api-2.XX  cannot be replaced with version 2.x

Sources of Information that we are monitoring & following: 

  1. Apache
  2. Oracle Document 2827611.1for Oracle Database, Java & other products regaarding the applicability of

Security Alert CVE-2021-44228 to Oracle on-premises products is being continually updated by Oracle as to the products that require or do not require patches.

  1. Redhat for JBoss EAP https://access.redhat.com/security/cve/cve-2021-44228
  2. AWS for RDS https://aws.amazon.com/security/security-bulletins/AWS-2021-006/ 
  1. Microsoft for Windows-based deployments 
  2. OWASP.org for adding this CVE to the OWASP list and the to the F5 WAF Managed Rulesets.
  3. Wildfly does not deploy Log4j-core instead you’ll find a shaded version that is not the affected log4j-core in the path /opt/Wildfly-##.#.#.Final/modules/system/layers/base/org/jboss/log4j/logmanager/main. Trax recommends applying 2.17.1 to all application servers running Java 8.
  4. The cost of ignoring the Log4j vulnerability: https://www.cisecurity.org/insights/blog/The-Cost-of-Ignoring-the-Log4j-Vulnerability