PARSEC Technical Information

The only known thing that has been found on OpenVMS to be potentially vulnerable to the CVE-2021-44228 vulnerability found in the Apache Log4j2 V2.14.1 or earlier code stream is the Attunity Connect STUDIO GUI tool. Information for this article is taken from several sites. Most of them documented at the bottom of this article.

This could potentially affect any other Java based GUI/environment, such as the Oracle GUI Database Installer. So you'll need to investigate those products.

The CVE writeup states:

Apache Log4j2 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0, this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.

VMS Software Incorporated stated that Apache Web Server (CSWS) and all the associated plugins or APIs are not affected by the vulnerability. Attunity Connect doesn't include Java by default, but if you use the Eclipse development environment, Attunity STUDIO GUI tool, then it's 1.x version of Log4j may potentially be affected. See the Mitigation section below for steps to alleviate the problem.

HPE no longer supports any versions of OpenVMS, but it's possible they will report on this due to the vulnerability. However, if VSI isn't affected, then HPE versions won't be either.

Process Software stated that all of the products that they develop (Multinet, TCPware, SSH for OpenVMS, PMDF, PreciseMail Anti-Spam Gateway, and VMS Authentication Module) are all unaffected by the vulnerability.

Log4j Version 2.15.0 and above is not affected by this feature unless it is enabled. If so, then follow the steps for earlier versions.

Log4j Version 2.10 and earlier can follow either of these two approaches:

1. Setting system property "log4j2.formatMsgNoLookups" to “true”
2. Removing the JndiLookup class from the classpath, for example:

  zip q -d log4j-core*.jar 
  org/apache/logging/log4j/core/lookup/JndiLookup.class
  

Java 8u121 protects against remote code execution by setting the default value for “com.sun.jndi.rmi.object.trustURLCodebase” and “com.sun.jndi.cosnaming.object.trustURLCodebase” to “False”. See Java 8u121 release notes for more information.

In Version 2.10 and above, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.

For Versions 2.7 through 2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m.

Log4j Versions 2.0-beta9 through 2.10.0, remove the JndiLookup class from the classpath:

zip q -d log4j-core*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

You may need to issue the following command to find the location of the jar file containing the JndiLookup.class.

$ DIRECTORY disk-name:[000000...]*.*JAR*

Further information on this topic can be found at the following locations:

MITRE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228

NVD: https://nvd.nist.gov/vuln/detail/CVE-2021-44228

Apache: https://logging.apache.org/log4j/2.x/security.html

VSI: https://vmssoftware.com/about/news/2021-12-14-cve-2021-44228-comments/

HPE: https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-a00120086en_us