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?