UPDATE 20 DECEMBER: The mitigation steps provided in this article also apply for the newly created CVE-2021-45105
UPDATE 16 DECEMBER: Many packages, Automic Infrastructure Manager, and the RA SOAP and RA JDE agents have new releases to fully patch this issue
UPDATE 15 DECEMBER: We are aware of the update from Apache that the vulnerability was not fully patched with Log4j2 2.15 and will be with 2.16 (CVE-2021-45046). This does not change any of the mitigation steps or impacted components in this article.
UPDATE 15 DECEMBER: Automic Infrastructure Manager added to list of affected components
Apache Log4j2 <=2.14.1 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.
There are some Action packs and RA Solutions for Automic Automation (AWA) and Continuous Delivery Automation (ARA) that are affected by the zero-day Apache log4j vulnerability.
The following Action Packs depend on Apache log4j 2 <= 2.10
Package.DM -> Resolved in PCK.AUTOMIC_DM 1.4.4 (released 16 December)
Package.IIS -> Resolved in PCK.AUTOMIC_IIS 1.4.2 (released 16 December)
Package.Tomcat -> Resolved in PCK.AUTOMIC_TOMCAT 1.5.3 (released 16 December)
Package.Weblogic -> Resolved in PCK.AUTOMIC_WEBLOGIC 1.4.3 (released 17 December)
Package.Websphere -> Resolved in PCK.AUTOMIC_IBM_WEBSPHERE 1.8.3 (released 16 December)
The following Action Packs, RA Solutions and the AAI Connector depend on log4j > 2.10
Package.Bond -> Resolved in PCK.AUTOMIC_BOND 1.3.3 (for versions 12.2 and 12.3) and 11.0.1 (for versions 21.x) (released 16 December)
Package.Atlassia.Jira -> Resolved in PCK.AUTOMIC_ATLASSIAN_JIRA 1.0.2 (released 16 December)
Package.Jenkins -> Resolved in PCK.AUTOMIC_JENKINS 1.2.0 (released 16 December)
Package.EXCEL -> Resolved in PCK.AUTOMIC_EXCEL 1.1.1 (released 16 December)
Package.JDBC -> Resolved in PCK.AUTOMIC_JDBC 1.4.2 (released 16 December)
Package.Siebel -> released 17 December
RA.Banner -> Resolved in RA Banner 4.1.1 (released 20 December)
RA.JD.Edwards -> Resolved with RA JD Edwards 2.2.1 (Released 16 December)
RA.Web.Service.SOAP -> Resolved with RA Web Service SOAP 4.6.1 (Released 16 December)
AAI.Automic (Connector) -> Resolved with AAI Automic Connector 2.1.2 (Released 17 December)
Automic Infrastructure Manager -> Resolved with Infrastructure Manager 2.0.1 (Released 16 December)
Are the JWPs and JCPs impacted by this vulnerability?
JWPs and JCPs are not impacted as they are using a version of log4j that is not impacted by this issue
Is AWI impacted by this vulnerability?
AWI is not impacted as it is not using the log4j-core components that are affected: https://logging.apache.org/log4j/2.x/security.html
How to tell if my system is impacted
Are there packages installed that are impacted?
Are there RA agent installed that are impacted?
Are any 3rd party components impacted?
There are sure to be 3rd party components that are impacted as the use of log4j2 is wide-spread. This article has a good breakdown of impacted known applications: https://github.com/NCSC-NL/log4shell/blob/main/software/README.md
It's important to note that Broadcom Support cannot provide an explanation on how to mitigate issues with third party applications. Those specific vendors will need to be contacted to provide information on mitigation or fixes.
AE/RA Components depending on log4j version 1.x :
This vulnerability can only be exploited under very specific circumstances in log4j. Precondition for that is that the log4j components integrates the JMS-listener .
None of our products using the log4J libraries are actually using the JMS-listener. So exploiting this vulnerability with applications from the AE solution depending on log4j 1.x is not possible at this time.
Coming releases of components depending on log4j 1.x will come with an updated log4j module version 2.16 or 2.71 if needed.
"If needed" stands here for the different reasons that might require a log4j update. This could be either an end of support, important technical changes in the component architecture or the detection of an new vulnerability in this component.
The Broadcom Automic Automation Engineering team plans on releasing hotfixes containing the latest log4j package by the end of the week of December 13.
Updating to fixed patches for Packages
The following packages can be updated using the "Packs" section in the Administration perspective in the AWI OR installed from file:
Package.Atlassia.Jira -> Can also be downloaded here
Package.Bond -> Can also be downloaded here
Package.DM -> Can also be downloaded here
Package.IIS -> Can also be downloaded here
Package.JDBC -> Can also be downloaded here
Package.Jenkins -> Can also be downloaded here
Package.Tomcat -> Can also be downloaded here
Package.Weblogic -> can also be downloaded here
The following packages can only be updated using the "Install From File" option:
The following package can only be downloaded by visiting the MarketPlace and requesting via the Contact Us button:
Package.Siebel -> Visit https://marketplace.automic.com/marketplace/browse/packagesiebel and click on the "Contact Us" button
For packages that can be updated via the Packs section of the Administration perspective (please note packages may be different in each client and so these steps may need to be taken in all clients). Full instructions can be found in Working with Packs and Plug-ins
Packages can also be updated by downloading them from the Automic marketplace and updated with the following:
Updating to fixed patches for RA Agents
The following updated RA Agents can be downloaded:
RA Banner 4.1.1 can be downloaded here
Follow the steps to load the respective jar file found in each RA Agent's respective documentation, only the solution needs to be updated, not the RA Core unless the current RA Core installation is incompatible due to being an older version.
Automic Infrastructure Manager
AAI Automic Connector
For instructions and Guidance for the AAI Automic Connector, please take a look at the article covering the vulnerability with AAI components here.
Until the patches are all released, or if the patch is not feasible for the environment (too old, incompatible, etc...), there are some mitigation steps that can be taken:
According to CVE-2021-44228, Java 1.8u121+ has built-in protection due to a default setting and protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false". Customers who are already using this Java version and didn't change the relevant properties should be fine.
For affected Action Packs, RA Solutions and the AAI Connector depending on log4j > 2.10, the vulnerable behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to TRUE. This can be done by altering the startup parameter to include:
Mitigating the risk with RA Agents
For example, if the service manager command being used to start an RA agent looks like this:
java -Xrs -Xmx1G -jar C:\automic\12.2.9\Agents\RA_AGENT\bin\ucxjcitx.jar
It can be updated to this:
java -Xrs -Xmx1G -Dlog4j2.formatMsgNoLookups=true -jar C:\automic\12.2.9\Agents\RA_AGENT\bin\ucxjcitx.jar
Here's a breakdown of where to find this:
As of 15 December, another step has been suggested to mitigate even more of the risk. It is recommended that the JndiLookup.class be removed from jar files of the affected components. The following steps can be taken for the Banner and JDE agents:
Mitigating Packages that might be impacted
The best and easiest way to be sure there is no risk to the integrity of running the installed Packages is to wait for new packages to be released within the week of December 13 and update the packages then. As a workaround, you could possibly do the following:
Can the system-wide environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS be used?
Some articles are pointing to being able to set an environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true - while this may be able to be used, the best is to update the commands as seen in the mitigation steps above