https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5645

In Apache Log4j 2.x before 2.8.2, when using the TCP socket server or UDP socket server to receive serialized log events from another application, a specially crafted binary payload can be sent that, when deserialized, can execute arbitrary code.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17571

Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data which can be exploited to remotely execute arbitrary code when combined with a deserialization gadget when listening to untrusted network traffic for log data. This affects Log4j versions up to 1.2 up to 1.2.17.

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

JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9488

Improper validation of certificate with host mismatch in Apache Log4j SMTP appender. This could allow an SMTPS connection to be intercepted by a man-in-the-middle attack which could leak any log messages sent through that appender.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=2022-23302

JMSSink in all versions of Log4j 1.x is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration or if the configuration references an LDAP service the attacker has access to. The attacker can provide a TopicConnectionFactoryBindingName configuration causing JMSSink to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-4104. Note this issue only affects Log4j 1.x when specifically configured to use JMSSink, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=2022-23305

By design, the JDBCAppender in Log4j 1.2.x accepts an SQL statement as a configuration parameter where the values to be inserted are converters from PatternLayout. The message converter, %m, is likely to always be included. This allows attackers to manipulate the SQL by entering crafted strings into input fields or headers of an application that are logged allowing unintended SQL queries to be executed. Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default. Beginning in version 2.0-beta8, the JDBCAppender was re-introduced with proper support for parameterized SQL queries and further customization over the columns written to in logs. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23307

CVE-2020-9493 identified a deserialization issue that was present in Apache Chainsaw. Prior to Chainsaw V2.0 Chainsaw was a component of Apache Log4j 1.2.x where the same issue exists.

• APM SaaS and APM on Premise 
• APM 9.7, 10.0, 10.1, 10.2, 10.3, 10.5, 10.6, 10.7.x, 11.x and 20.x/21.x

APM Agents:

Java Agent and core APMIA are not vulnerable to any of these CVEs because we are using a customized limited package of log4j 1.2.17 classes that excludes all classes that are not strictly needed and all vulnerable classes are excluded.

APMIA though may have some extensions that include third party dependencies, which may still contain other versions of log4j. But all code is scanned and the agent teams that are responsible for these extensions have addressed them. 

APM Servers:

CVE-2022-23307, CVE-2020-9488 (CRITICAL) - Apache Log4j 1.2.x

Vulnerability Description: CVE-2020-9493 identified a deserialization issue that was present in Apache Chainsaw. Prior to Chainsaw V2.0 Chainsaw was a component of Apache Log4j 1.2.x where the same issue exists.

This is described in some detail in https://blog.sonatype.com/new-log4j-1.x-cves-and-critical-chainsaw-vulnerability-what-to-do

It is vulnerable in default configuration, thus high severity score, but only if you run the Chainsaw. That is if you run:
java -cp log4j-1.2.17.jar org.apache.log4j.chainsaw.Main

Running the Chainsaw this way it starts a TCP server accepting connection on port 4445 from any source IP address. The log4j1 can be configured with socket appender that that points to host:4445 then the log messages appear in the Chainsaw UI. The vulnerable part is the Chainsaw, but APM is not running this and it is unlikely that anybody would use included jar file to run Chainsaw. With our modified version log4j-1.2.17-cloudera1-nonet.jar does not contain org.apache.log4j.net package so the socket appender is removed so it is even less likely because that log4j would not be capable to send logs to Chainsaw.

CVE-2022-23302 (HIGH) - Apache Log4j 1.x

Vulnerability Description: JMSSink in all versions of Log4j 1.x is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration or if the configuration references an LDAP service the attacker has access to. The attacker can provide a TopicConnectionFactoryBindingName configuration causing JMSSink to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-4104. Note this issue only affects Log4j 1.x when specifically configured to use JMSSink, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.

CVE description contains "Note this issue only affects Log4j 1.x when specifically configured to use JMSSink, which is not the default."

Our modified version log4j-1.2.17-cloudera1-nonet.jar does not contain org.apache.log4j.net package so it does not contain JMSSink class.
APM does not configure log4j to use JMS.

CVE-2022-23305 (CRITICAL) - Apache Log4j 1.2.x

Vulnerability Description: By design, the JDBCAppender in Log4j 1.2.x accepts an SQL statement as a configuration parameter where the values to be inserted are converters from PatternLayout. The message converter, %m, is likely to always be included. This allows attackers to manipulate the SQL by entering crafted strings into input fields or headers of an application that are logged allowing unintended SQL queries to be executed. Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default. Beginning in version 2.0-beta8, the JDBCAppender was re-introduced with proper support for parameterized SQL queries and further customization over the columns written to in logs. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.

The CVE description contains "Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default."
APM does not configure log4j to use JDBC.

CVE-2021-4104 (HIGH) - Apache Log4j 1.2.x

Vulnerability Description: JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.

The CVE description contains "Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default."
APM does not configure log4j to use JMS.

CVE-2019-17571 (CRITICAL) - Apache Log4j 1.2 up to 1.2.17

Vulnerability Description: Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data which can be exploited to remotely execute arbitrary code when combined with a deserialization gadget when listening to untrusted network traffic for log data. This affects Log4j versions up to 1.2 up to 1.2.17.

The SocketServer class is vulnerable to deserialization of untrusted data. APM does not configure log4j to use socket server.
Our modified version log4j-1.2.17-cloudera1-nonet.jar does not contain org.apache.log4j.net package so it does not contain org.apache.log4j.net so the socket server is removed.

CVE-2017-5645 (CRITICAL) - Apache Log4j 2.x before 2.8.2

Vulnerability Description: In Apache Log4j 2.x before 2.8.2, when using the TCP socket server or UDP socket server to receive serialized log events from another application, a specially crafted binary payload can be sent that, when deserialized, can execute arbitrary code.

The CVE description contains "In Apache Log4j 2.x before 2.8.2, when using the TCP socket server or UDP socket server to receive serialized log events from another application, etc."
APM does not configure log4j to use socket server.
Our modified version log4j-1.2.17-cloudera1-nonet.jar does not contain org.apache.log4j.net package so it does not contain org.apache.log4j.net so the socket server is removed.

Should you have any further questions or concerns, please open a case with Broadcom Support.