Advisory: Log4j Zero Day Security Vulnerability
Posted by Aly Essa, Last modified by Aly Essa on 20 December 2021 01:25 PM
Note: This is the only article that will be updated with findings from our development and security teams.
What is the Log4j CVE-2021-44228 vulnerability?
The CVE-2021-44228 vulnerability is a day zero security vulnerability under the highest severity rank that allows attackers to execute arbitrary code by injecting attacker-controlled data into a logged message. Using this vulnerability, attackers can execute code loaded from LDAP servers when message lookup substitution is enabled. This allows attackers to execute whatever code they wish to on systems that have an application running log4j, which presents a massive security concern.
For more information regarding this vulnerability, please visit the following links:
What resources are exposed to this vulnerability?
To be subject to this vulnerability outlined by CVE-2021-44228, you must meet two specific conditions.
The first condition that must be met is that your application must be using a log4j2 library implementation between versions 2.0.0 and 2.14.1. These versions of Log4j2 introduced a lookup mechanism that allows the logger to perform string substitution using the JNDI protocol. This substitution mechanism is the item that is causing the CVE-2021-44228 security vulnerability, and it is present in all log4j2 libraries that exist within the version range. It is also important to note that this substitution mechanism is only current with the version 2 implementations of log4j. Version 1 log4j libraries do not have the JNDI substitution mechanism implemented, and because of this, they are not subject to security vulnerability.
The second condition that must be met is that your application must be running on a Java version older than version 1.8.121. Before this release, Java 8 did not have any protection for applications attempting to run remote code execution in ways similar to the CVE-2021-44258 vulnerability. In version 1.8.121, Java introduced logic that prevents remote code execution from being executed by default. With that in mind, if you are running your Java application with a version that is higher than 1.8.121, then you will not be subject to the CVE-2021-44228 security vulnerability.
What impact does CVE-2021-44228 have on the FileCatalyst applications?
When it comes to FileCatalyst applications, CVE-2021-44228 has a low impact. The low impact is because the majority of the FileCatalyst applications do not use log4j for logging information during the application’s lifecycle. The majority of the FileCatalyst applications instead use the standard java.util.logger package that is bundled within the JREs that are distributed with each application. This logger implementation is separate from log4j, and thus, it is not subject to the CVE-2021-44228 vulnerability.
Now, some FileCatalyst applications do reference log4j within their classpath definitions. However, these references are not subject to the CVE-2021-44228 log4j vulnerability for the reasons illustrated below.
What FileCatalyst applications are not at risk?
The following is a list of FileCatalyst applications that do not reference log4j and are not at risk to the CVE-2021-44228 security vulnerability.
The following is a list of FileCatalyst applications that do reference log4j but are also not at risk to the CVE-2021-44228 security vulnerability:
What FileCatalyst applications are at risk?
Currently, no applications are at risk from CVE-2021-44228. All FileCatalyst applications either do not reference log4j as part of their dependencies or reference a version that does not have the string substitution resource required for the vulnerability.
What can I do to protect myself from this vulnerability?
Currently, there isn’t anything that you will need to do to protect yourself from this security vulnerability. All FileCatalyst applications now do not meet the requirements for CVE-2021-44228, and that will ensure that you are safe from this issue. If you want to take extra steps to ensure that you are not subject to vulnerability, then there are a couple of things that you can do.
The first option you can do is ensure that all FileCatalyst applications are upgraded to the most recent available versions. Upgrading to the most recent will allow you to utilize the security fixes that FileCatalyst has implemented within their applications. It will ensure that you have the most up-to-date security fixes.
The second option you have access to is setting the system property “log4j2.formatMsgNoLookups” to have a true value for both the FileCatalyst Server and FileCatalyst Workflow applications. While setting this value will not do anything within the current releases of the software (due to the log4j implementation not being the correct version), it will set the value and ensure that that your system will not expose the CVE-2021-44228 security vulnerability.
The following steps will work on Linux and Windows OS:
How do I verify that I am protected against CVE-2021-44228?
To check for whether or not you are exposed to the CVE-2021-44228 vulnerability within the FileCatalyst Workflow application, you can take the following steps:
When you perform these steps, you should see something similar to this within the FileCatalyst Workflow instance:
As you can see, the FileCatalyst Workflow application outputs the string in the log file and does not attempt to connect to the LDAP URL. With this, you are protected from the CVE-2021-44228 vulnerability.
What is FileCatalyst doing to protect customers from this vulnerability further?
To protect people from security vulnerabilities in third-party libraries, FileCatalyst continuously monitors dependencies by using a security tool to scan each dependency and check its version against the list of currently open security issues for the library being checked. If a library is found to have a security vulnerability, then the development team is notified, and an investigation into the issue is started. Once the analysis is complete, the development team implements a solution, and then the next release will contain a fix for the identified problem.
In the case of the log4j CVE-2021-44228 vulnerability, the security tool identified the problem as soon as the issue was found. Once the problem was found, the FileCatalyst team quickly began investigating the log4j references within the codebase. During this investigation, the team determined which CVE-2021-44228 vulnerability impacted applications and how the exposure might be addressed. While no work is currently needed to address the vulnerability, the FileCatalyst team is looking into updating the log4j implementation to the most recent version of the library. Performing this upgrade will bring in all the security fixes that log4j has implemented since the release. It will also bring in the major fix required for the CVE-2021-44228 security vulnerability to be addressed.
FileCatalyst is always seeking to provide secure, safe file transfers to every company worldwide, and we actively try to address security concerns as quickly as possible. We appreciate your patience with this log4j issue and ensure that we are taking adequate steps to ensure that customers who use FileCatalyst applications are not put at risk.
When it comes to the CVE-2021-45046 vulnerability, FileCatalyst applications are not exposed and are not subject to any issues contained within the vulnerability. Similar to the previous issue (CVE-2021-44258) CVE-2021-45046 requires that the application must be using a 2.x implementation of log4j to be impacted. Currently, FileCatalyst applications only reference a log4j instance that is version 1.2.17. This older log4j version falls outside of the impact version list, and thus, the FileCatalyst applications are not impacted by CVE-2021-45046.
When it comes to this vulnerability, FileCatalyst applications are not exposed and are not subject to the vulnerability. In order to expose this vulnerability to users, applications must use a 2.x release of log4j within their application distributable. Currently, FileCatalyst applications do not reference any 2.x release of log4j within their distributable. While there is a reference to a log4j implementation, the version of the implementation is 1.2.17, and as such, is not vulnerable to the CVE-2021-45105.