A previously unknown zero-day vulnerability in Log4j 1.x and 2.x has been reported on December 9, 2021 . We would like to reassure our Veryant users that this vulnerability would only affect isCOBOL Webclient 2021R1 and 2021R2.
Also, this vulnerability only affects you if your COBOL application uses the following isCOBOL property:
iscobol.logclass=com.iscobol.logger.Slf4jLogger
to specify that you use Log4J instead of our default internal logger. If your application follows these three situations, your application could be vulnerable to CVE-2021-44228. In this case you can apply the following remediation:
- Download the latest Log4j mitigated version 2.15.0
- If you can't upgrade and you are using version log4j2.x version >=2.10 and <= 2.14.1, set the system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
- If you use version >=2.0-beta9 and <=2.10.0, mitigation is to remove log4j’s JndiLookup class from JVM’s classpath as under: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
If you are using Log4j 1.x, you are impacted by this vulnerability only if you are using JMS Appenders. To verify if you are using this appender, double check your log4j configuration files for presence of org.apache.log4j.net.JMSAppender class. Having said this, Log4j 1.x has reached end of life as of August 2015 and patches are no longer available. It has its own set of remote code execution issues and should be updated.
Please bear in mind that even if your application does not use log4j directly, its surrounding infrastructure such as the application server, message queue server, database server, network devices may be using that combination of Java and log4j version that expose you to this vulnerability.
On December 16, 2021, we have released patched versions of isCOBOL Webclient 2021R1 (b1041.11) and 2021R2 (b1050.9) that include a fixed version of Log4j 2 (2.15.0). If you need a fix for another version, please contact us at support@veryant.com.
