DX APM 2x Security Vulnerabilities that are False Positive
Article ID: 233773
Updated On:
Products
Issue/Introduction
This page lists security vulnerabilities reported by Black Duck/Code Insight/Twistlock/Qualys/OWASP-check and other tools against APM 20.x and 21.x releases that are false positive.
Environment
APM 2x versions
Resolution
This page lists security vulnerabilities reported by Black Duck/Code Insight/Twistlock/Qualys/OWASP-check and other tools against APM 20.x and 21.x releases that are false positive. The security vulnerabilities are either fixed by patching such as Apache Axis 1.4 or are not applicable to APM 20.x/21.x. APM 10.7 Security Vulnerabilities that are False Positive
CVE-2019-9193 (HIGH) - postgres 10.16
Vulnerability Description: ** DISPUTED ** In PostgreSQL 9.3 through 11.2, the "COPY TO/FROM PROGRAM" function allows superusers and users in the 'pg_execute_server_program' group to execute arbitrary code in the context of the database's operating system user. This functionality is enabled by default and can be abused to run arbitrary operating system commands on Windows, Linux, and macOS. NOTE: Third parties claim/state this is not an issue because PostgreSQL functionality for ‘COPY TO/FROM PROGRAM’ is acting as intended. References state that in PostgreSQL, a superuser can execute commands as the server user without using the ‘COPY FROM PROGRAM’.
This is not a vulnerability because it is a matter of proper configuration of roles and not some defect in programming. See also https://www.postgresql.org/about/news/cve-2019-9193-not-a-security-vulnerability-1935/. Also, the acc role under which ACC operaters does not have superuser privileges.
CVE-2021-3393 (MEDIUM) - postgres 10.16
Vulnerability Description: An information leak was discovered in postgresql in versions before 13.2, before 12.6 and before 11.11. A user having UPDATE permission but not SELECT permission to a particular column could craft queries which, under some circumstances, might disclose values from that column in error messages. An attacker could use this flaw to obtain information stored in a column they are allowed to write but not read.
The security vulnerability CVE-2021-3393 reported against postgres is false positive because it is related to privileges handling on individual columns. We do not use such find grained per database column priviliges management in ACC.
CVE-2021-35515, CVE-2021-35516, CVE-2021-35517, CVE-2021-36090 - commons-compress 1.9
Vulnerability Description: When reading a specially crafted 7Z or tar or zip archive, the construction of the list of codecs that decompress an entry can result in an infinite loop. This could be used to mount a denial of service attack against services that use Compress' sevenz package.
The issue is resolved in the latest version of commons-compress, 1.21. The catch is, this newer release is only compatible with version 1.8 and above of java while with agent we have to maintain backward compatibility with java 6 (pre 21.10) and Java 7 (21.10 onwards).
APM agent only decompresses streams from trusted file system location, we do not accept compressed streams from external sources. So these vulnerabilities are of low concern as the attacker will require access to the trusted filesystem location under the agent folder.
CVE-2021-42340 (BDSA-2021-3085) (HIGH) - Apache Tomcat 9.0.48 in ACC
Vulnerability Description: The fix for bug 63362 present in Apache Tomcat 10.1.0-M1 to 10.1.0-M5, 10.0.0-M1 to 10.0.11, 9.0.40 to 9.0.53 and 8.5.60 to 8.5.71 introduced a memory leak. The object introduced to collect metrics for HTTP upgrade connections was not released for WebSocket connections once the connection was closed. This created a memory leak that, over time, could lead to a denial of service via an OutOfMemoryError.
tomcat-embed-el-9.0.50.jar in ACC is just an expression language implementation from Tomcat. It is not the entire webapp server Tomcat. This vulnerability is not valid for this JAR and the ACC product.
CVE-2022-42252 (BDSA-2022-3105) (HIGH) - Apache Tomcat 10.1.0-M17 in http-collector
Vulnerability Description: If Apache Tomcat 8.5.0 to 8.5.82, 9.0.0-M1 to 9.0.67, 10.0.0-M1 to 10.0.26 or 10.1.0-M1 to 10.1.0 was configured to ignore invalid HTTP headers via setting rejectIllegalHeader to false (the default for 8.5.x only), Tomcat did not reject a request containing an invalid Content-Length header making a request smuggling attack possible if Tomcat was located behind a reverse proxy that also failed to reject the request with the invalid header.
Path: <image/repo path>/apmia/extensions/http-collector/lib/external/jakarta.annotation-api.jar!/jakarta/annotation/security/
The http-collector extension uses jersey(for JAX-RS) with grizzly web server, it has internally 'jakarta.annotation-api' jar packaged as jersey depends on jakarta annotations API.
The security vulnerability is false positive as it points to wrong component Apache Tomcat with Origin ID tomcat-annotations-api:10.1.0-M17 but it wrongly points to jakarta.annotation-api:2.0.0 jar.
Resolution: Update component name to "Jakarta Annotations API", version to "2.0.0" and Orgin ID maven jakarta.annotation:jakarta.annotation-api:2.0.0 in BlackDuck project.
CVE-2017-5645, CVE-2019-17571, CVE-2021-4104, CVE-2020-9488, CVE-2022-23302, CVE-2022-23305, CVE-2022-23307 (CRITICAL, HIGH, LOW) - custom log4j 1.x in APM agents
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.
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.
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.
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.
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.
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.
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.
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.
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.
CVE-2022-22965 (CRITICAL) - Spring Framework RCE via Data Binding on JDK 9+
Vulnerability Description: A Spring MVC or Spring WebFlux application running on JDK 9+ may be vulnerable to remote code execution (RCE) via data binding. The specific exploit requires the application to run on Tomcat as a WAR deployment. If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit. However, the nature of the vulnerability is more general, and there may be other ways to exploit it.
These are the prerequisites for the exploit:
- JDK 9 or higher
- Apache Tomcat as the Servlet container
- Packaged as WAR
- spring-webmvc or spring-webflux dependency
There are some new vulnerabilities in Spring https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/ . There is a spring cloud function vulnerability - APM does not use that. There is a "spring4shell" vulnerability relaying on classloader manipulation through query parameters of http request.
Spring4shell analysis:
Exploit is explained here in Chinese: https://github.com/TheGejr/SpringShell/blob/master/Vulnerability%20Analysis%20%5BCHINESE%5D.pdf
This is related to insufficient black list is in (now it is fixed in the latest version): https://github.com/spring-projects/spring-framework/blob/d4192b9d355a2d4b0be959e076c255d8b5f01bcf/spring-beans/src/main/java/org/springframework/beans/CachedIntrospectionResults.java#L290
On JDK 9+ the new method "getModule()" on Class class allows an attacker to access the classloader object.
Normally, even classloader object is not very useful but in case of Apache Tomcat where WAR is deployed the WebAppClassLoaderBase is the classloader that enables access to some objects that exploit uses (specifically Tomcat's AccessLogValve through path class.classLoader.resources.context.parent.pipeline.first).
- In APM ACC I do not see the same classloader (there is jdk.internal.loader.ClassLoaders.AppClassLoader instead that does not expose the field that exploit uses nor it does not seem to expose other fields usable for exploit). Additionally ACC does not generally use @RequestMapping methods that would rely on ServletModelAttributeMethodProcessor which is necessary for the exploit, but when such a method is added to ACC, the bean paths are resolved.
- In APM NG components I do not see the same classloader. (again AppClassLoader which is safe)
- In APM EM and VW I see that it is using java 8, so not 9+.
In other APM components I see in APM installation:
- dxi-adminui: using apache tomee with WARs. spp war uses spring web however it uses java 8 so it is safe.
- dxi-scheduler: using apache tomee with WARs. sppsvc war uses spring web however it uses java 8 so it is safe.
The conclusion is that APM is safe.
CVE-2022-21449 (HIGH) - Oracle Java - Improper ECDSA signature verification
Vulnerability Description: Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries). Supported versions that are affected are Oracle Java SE: 17.0.2, 18; Oracle GraalVM Enterprise Edition: 20.3.5, 21.3.1 and 22.0.0.2. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. * Oracle issued revision 2 of the advisory https://www.oracle.com/security-alerts/cpuapr2022.html correcting that older java versions are not affected. So the issue applies to only java 15 and newer as specified in https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/ and out of those 17.0.2 and 18 are supported.
This CVE-2022-21449 is not affecting APM server itself directly:
- APM uses by default BCFIPS security provider which has different implementation than default Java JCE.
- In addition, JWT-like tokens used in APM do not rely on ECDSA signature for the security. They are signed with ECDSA signature, but their validity is based on embedded token (that is used to support revocation features). E.g. ability of attacker to forge signature of the JWT does not make system insecure without ability insert token into token DB.
- While attack fails for r and s being zero, there are other numbers for which attack can be also performed. It is enough for s to be zero modulo prime order of the curve and that is not prevented in JOSE to DER conversion - see https://twitter.com/neilmaddog/status/1517232777841811456
On the other hand, there is an attack where java code in role of TLS client will trust invalid certificate when running on affected java runtime as demonstrated here https://github.com/khalednassar/CVE-2022-21449-TLS-PoC This could happen in APM too in following situations: APM Agent / Agent Controller / Cloud proxy configured for validating certificates and running on affected java runtime. Java version is out of control of APM here except for Agent Controller which in some cases (Infrastructure Agent) bundles OpenJDK/AdoptOpenJDK 1.8 (OpenJDK 1.8 is not vulnerable according to https://openjdk.java.net/groups/vulnerability/advisories/2022-04-19). We recommend that customers upgrade their java runtimes used on clients to versions that are not vulnerable. Cloud Proxy can be configured (it is not a default) for FIPS mode using environment variable APM_FIPS_ENABLE=true. In FIPS mode the vulnerable java runtime cryptography code will not be used.
CVE-2016-1000027 (CRITICAL) - Spring Framework - HTTP invoker
Vulnerability Description: Pivotal Spring Framework, all versions before 6.0, suffers from a potential remote code execution (RCE) issue if used for Java deserialization of untrusted data. Depending on how the library is implemented within a product, this issue may or not occur, and authentication may be required. NOTE: The vendor's position is that untrusted data is not an intended use case. The product's behavior will not be changed because some users rely on deserialization of trusted data.
See also: https://github.com/spring-projects/spring-framework/issues/24434#issuecomment-579669626
This gist of this vulnerability is the potential that Java serialization can be abused for RCE. The defense is either not to use the HTTP invoker functionality, or authentication which prevents deserialization from untrusted sources. APM products do not use the HTTP invoker functionality anywhere.
CVE-2022-34169 (CRITICAL) - Apache Xalan Java XSLT library
Vulnerability Description: The Apache Xalan Java XSLT library is vulnerable to an integer truncation issue when processing malicious XSLT stylesheets. This can be used to corrupt Java class files generated by the internal XSLTC compiler and execute arbitrary Java bytecode. The Apache Xalan Java project is dormant and in the process of being retired. No future releases of Apache Xalan Java to address this issue are expected. Note: Java runtimes (such as OpenJDK) include repackaged copies of Xalan.
See also: https://www.suse.com/security/cve/CVE-2022-34169.html and https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34169
The Apache Xalan Java XSLT library is not present in any of the SaaS agents. The APM SaaS agents aren't affected by this vulnerability.
CVE-2022-42889 (CRITICAL) - Apache Commons Text (<1.10)
Vulnerability Description: A remote code execution vulnerability in Apache Commons Text string placeholder replacement class StringSubstitutor. When the class is used with defaults replacement resolvers, via StringSubstitutor.createInterpolator(), an input text attacker controlled by attacker can cause remote code execution. Other StringSubstitutor uses that supply own variable resolver are safe.
See also: https://nakedsecurity.sophos.com/2022/10/18/dangerous-hole-in-apache-commons-text-like-log4shell-all-over-again/ but note that while it is in some ways similar to the famous Log4Shell vulnerability, the usage of text substitution is not as widespread as is logging so opportunities to exploit it are reduced.
In APM the library is used by ACC component, but it is used in only safe ways with explicit variable resolver.
APM proprietary libraries mapping with OpenSource Libraries (AsyncHttpClient, Elasticsearch and Spring Boot)
BlackDuck is wrongly identifying APM internal extension libraries matching with opensource libraries as they share same name as opensource ones.
In this scenario, BlackDuck doesn't identify the version and it list out vulnerabilities related to all versions of that opensource library.
Identification: Source Matches path matched with the details mentioned below.
Here is such kind of false positive list:
| Component Name | Version | Possible CVEs | Jar name | Path | Archive Context and Path | APM Agent Extension Name | |
|---|---|---|---|---|---|---|---|
| Component Name | Version | Possible CVEs | Jar name | Path | Archive Context and Path | APM Agent Extension Name | |
| 1 | AsyncHttpClient | 1.9.16 | CVE-2017-14063 | async-http-client.jar | /lib/async-http-client.jar |
<image-or-repo-scan-path>/wily/extensions/deploy/async-http-client.tar.gz!/lib/async-http-client.jar <image-or-repo-scan-path>/com/ca/apm/agent/bundles/java/core/dist/2022.11.0.1/dist-2022.11.0.1.tar.gz!/async-http-client-2022.11.0.1-java-gae.tar.gz!/lib/async-http-client.jar |
async-http-client.tar.gz |
| 2 | Elasticsearch | 0.16.3 | CVE-2015-5377, CVE-2019-7611(BDSA-2019-0721) BDSA-2021-2401 CVE-2015-4165 CVE-2015-1427 CVE-2014-3120(BDSA-2014-0188) |
elasticsearch.jar | lib/elasticsearch.jar | <image-or-repo-scan-path>/wily/extensions/deploy/elasticsearch.tar.gz!/lib/elasticsearch.jar <image-or-repo-scan-path>/com/ca/apm/agent/bundles/java/core/dist/2022.11.0.1/dist-2022.11.0.1.tar.gz!/elasticsearch-2022.11.0.1-java-gae.tar.gz!/lib/elasticsearch.jar |
elasticsearch.tar.gz |
| 3 | Elasticsearch | 6.1.1 | CVE-2018-3831(BDSA-2018-3334) CVE-2019-7611(BDSA-2019-0721) BDSA-2021-2401 BDSA-2018-2111 |
||||
| 4 | Elasticsearch | 5.4.1 | CVE-2019-7611(BDSA-2019-0721) BDSA-2021-2401 |
||||
| 5 | Spring Boot | v1.2.0.M1 | CVE-2017-8046 (BDSA-2017-2964) CVE-2021-26987 CVE-2022-22965 (BDSA-2022-0858) BDSA-2018-1076 CVE-2022-27772 |
spring-boot.jar | lib/spring-boot.jar | <image-or-repo-scan-path>/wily/extensions/deploy/spring-boot.tar.gz!/lib/spring-boot.jar <image-or-repo-scan-path>/com/ca/apm/agent/bundles/java/core/dist/2022.11.0.1/dist-2022.11.0.1.tar.gz!/spring-boot-2022.11.0.1-java-gae.tar.gz!/lib/spring-boot.jar |
spring-boot.tar.gz |
| 6 | Spring Boot | 2.0.0.M3 | CVE-2022-22965 (BDSA-2022-0858) BDSA-2018-1076 CVE-2022-27772 (BDSA-2022-0856) BDSA-2018-0598 |
||||
Additional Information
Feedback
