search cancel

APM 10.7 & 10.8 Security Vulnerabilities that are False Positive

book

Article ID: 185748

calendar_today

Updated On:

Products

CA Application Performance Management Agent (APM / Wily / Introscope) CA Application Performance Management (APM / Wily / Introscope) INTROSCOPE DX Application Performance Management

Issue/Introduction

This page lists security vulnerabilities reported by Black Duck/Code Insight/TechStack and other tools against APM 10.7 and 10.8 that are false positive. The  security vulnerabilities are either fixed by patching such as Apache Axis 1.4 or it is not applicable to APM 10.x.

Environment

APM 10.7.x

 

Resolution

 

  • CVE-2012-5784 (MEDIUM) - Apache Web Services Axis 1.4
  • CVE-2014-3596 (MEDIUM) - Apache Web Services Axis 1.4
  • CVE-2018-8032 (MEDIUM) - Apache Web Services Axis 1.4
  • CVE-2019-0227 (MEDIUM) - Apache Web Services Axis 1.4
  • CVE-2017-8046 (HIGH) - Spring Boot 1.4.2
  • CVE-2016-5007, CVE-2018-1258 (MEDIUM) - spring-framework 3.2.18.RELEASE
  • CVE-2019-3778 (MEDIUM) - spring-security-oauth2-2.0.16.RELEASE.jar
  • CVE-2018-10237 (MEDIUM - agent jars) - Guava 
  • CVE-2020-8908 (BDSA-2020-3736) (LOW - agent jars) - Guava 
  • CVE-2018-1313 (BDSA-2018-1426) (MEDIUM - agent jars) - Apache Derby
  • CVE-2018-11771 (MEDIUM - agent jars) - commons-compress
  • CVE-2020-1938 (CRITICAL) - cpe:2.3:a:apache:tomcat (aka Ghostcat)
  • CVE-2021-30639 (HIGH) - Tomcat libraries
  • CVE-2021-30640 (MEDIUM) - Tomcat libraries
  • CVE-2021-41079 (HIGH) - Tomcat libraries
  • CVE-2014-0114 (HIGH) (struts ActionForm object) Apache Struts 1.x-1.3.10, 2.x-2.3.16.2
  • CVE-2019-10086 (HIGH) - org.apache.commons_beanutils-1.9.3.jar
  • CVE-2014-1904 (MEDIUM) (Formtag) Spring Framework 3.0.0-3.2.8, 4.0.0-4.0.2
  • CVE-2014-0054 (MEDIUM) (Jaxb2RootElementHttpMessageConverter) Spring 3.0.0-3.2.7, 4.0.0-4.0.1
  • CVE-2015-3192 (MEDIUM) (XML bomb) Spring Framework 3.x-3.2.1, 4.x - 4.1.7
  • CVE-2018-1270 (CRITICAL) (Stomp message protocol)  Spring Framework 5.0 to 5.0.4, 4.3-4.3.15   CVE-2018-1275 (CRITICAL) (Stomp message protocol) All the Same
  • CVE-2013-6429 (MEDIUM) (SourceHttpMessageConverter) Spring MVC 3.x-3.2.8, 4.x-4.0.2
  • CVE-2018-1272 (MEDIUM) (Multipart Requests) Spring Framework 5.0 - 5.0.4, 4.3-4.3.14
  • SPR-7779 (LocaleChangeInterceptor) Spring Framework 3.x-3.0.6
  • CVE-2019-10086 (HIGH) (BeanIntrospector) Apache Commons Beanutils 1.9.2
  • CVE-2014-0225 (HIGH) Spring Framework 4.0.0 to 4.0.4, 3.0.0 to 3.2.8, XXE attack
  • CVE-2014-3578 (MEDIUM) Spring Framework 3.x before 3.2.9 and 4.0 before 4.0.5
  • CVE-2017-5638 (CRITICAL) Apache Struts 2 2.3.x before 2.3.32 and 2.5.x before 2.5.10.1
  • CVE-2017-5638 (HIGH) Apache Struts 2.1.1 through 2.3.x before 2.3.34 and 2.5.x before 2.5.13
  • CVE-2020-27216 (HIGH) - Jetty Temp Files
  • CVE-2019-11358 (MEDIUM)  - docker-utility-2.0.25.jar: jquery-3.1.1.min.js
  • CVE-2020-11022 (MEDIUM)  - docker-utility-2.0.25.jar: jquery-3.1.1.min.js
  • CVE-2020-11023 (MEDIUM) - docker-utility-2.0.25.jar: jquery-3.1.1.min.js
  • CVE-2017-12629 (CRITICAL) - Apache Lucene 4.7.2
  • CVE-2017-9096 (HIGH) - iText 1.3.1, 2.1.3, 2.0.7
  • CVE-2021-43113 (CRITICAL) - iText command injection via a CompareTool filename
  • CVE-2017-16853 (HIGH) - OpenSAML before 2.6.1
  • CVE-2021-41616 (CRITICAL) - Apache Hive
  • 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
  • CVE-2022-23307, CVE-2020-9488 (CRITICAL) - Apache Log4j 1.2.x
  • CVE-2022-23302 (HIGH) - Apache Log4j 1.x
  • CVE-2022-23305 (CRITICAL) - Apache Log4j 1.2.x
  • CVE-2021-4104 (HIGH) - Apache Log4j 1.2.x
  • CVE-2019-17571 (CRITICAL) - Apache Log4j 1.2 up to 1.2.17
  • CVE-2017-5645 (CRITICAL) - Apache Log4j 2.x before 2.8.2
  • CVE-2021-43557 (HIGH) - Apache Hive
  • CVE-2021-45232, CVE-2022-24112 (CRITICAL) - Apache Hive
  • CVE-2022-22965 (CRITICAL) - Spring Framework RCE via Data Binding on JDK 9+
  • CVE-2022-24197 (MEDIUM) - iText v7.1.17
  • CVE-2022-21449 (HIGH) - Oracle Java - Improper ECDSA signature verification
  • CVE-2016-1000027 (CRITICAL) - Spring Framework - HTTP invoker
  • CVE-2022-25757, CVE-2022-29266 (HIGH, CRITICAL) - Apache Hive
  • CVE-2022-34169 (CRITICAL) - Apache Xalan Java XSLT library
  • CVE-2022-42889 (CRITICAL) - Apache Commons Text (<1.10)

 

CVE-2012-5784 (MEDIUM) - Apache Web Services Axis 1.4

Vulnerability Description: Apache Axis 1.4 and earlier, as used in PayPal Payments Pro, PayPal Mass Pay, PayPal Transactional Information SOAP, the Java Message Service implementation in Apache ActiveMQ, and other products, does not verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate.

BD Component Name BD Component Version BD KB Id BD Release Id Vulnerability Severity CVSS Count Files Folder File Name
Apache Web Services Axis 1.4 apache-webservicesaxis 408255 CVE-2012-5784 Medium 5.8 8

mom/product/enterprisemanager/configuration/

org.eclipse.osgi/bundles/31/1/.cp/WebContent/WEB-INF/lib

axis.jar

The following security vulnerabilities CVE-2012-5784 & CVE-2014-3596 were reported on Apache Web Services Axis 1.4 for APM 10.3. 

Unfortunately, there is no direct upgrade path available and Axis2 is not an option (due to the different architecture) so Axis 1.4 is patched, see details in the tools repository under the directory 3rdparty/org.apache.axis/1.4.1.1924.

Links to the vulnerabilities in National Vulnerability database:
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-5784

 

Impact: apache:axis:1.4 and previous versions

Available patch: https://issues.apache.org/jira/secure/attachment/12662672/CVE-2014-3596.patch The proposed patch resolves both vulnerabilities CVE-2012-5784 (AXIS-2883) and CVE-2014-3596.

This patch was applied on org.apache.axis.components.net.JSSESocketFactory.java, the pom.xml in the top repository was modified as follows:
<dependency>
<groupId>com.ca.apm.osgilibs</groupId>
<artifactId>org.apache.axis</artifactId>
- <version>1.4.1.1923</version>
+ <version>1.4.1.1924</version>
</dependency>

As a result of the building (using JDK 1.4.2_13-b06 on top of axis-1.4.jar - size 1599570) the following files were used for the patch 1.4.1.1924:
JSSESocketFactory.class
JSSESocketFactory$Rdn.class
JSSESocketFactory$TypeAndValue.class
MANIFEST.MF

and org.apache.axis_1.4.1.1924.jar & org.apache.axis_1.4.1.1924.pom were uploaded to the APM Artifactory.

CVE-2014-3596 (MEDIUM) - Apache Web Services Axis 1.4

Vulnerability Description: The getCN function in Apache Axis 1.4 and earlier does not properly verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via a certificate with a subject that specifies a common name in a field that is not the CN field.  NOTE: this issue exists because of an incomplete fix for CVE-2012-5784.

BD Component Name BD Component Version BD KB Id BD Release Id Vulnerability Severity CVSS Count Files Folder File Name
Apache Web Services Axis 1.4 apache-webservicesaxis 408255 CVE-2014-3596 Medium 5.8 8

mom/product/enterprisemanager/configuration/

org.eclipse.osgi/bundles/31/1/.cp/WebContent/WEB-INF/lib

axis.jar

The following security vulnerabilities CVE-2012-5784 & CVE-2014-3596 were reported on Apache Web Services Axis 1.4 for APM 10.3. 

Unfortunately, there is no direct upgrade path available and Axis2 is not an option (due to the different architecture) so Axis 1.4 is patched, see details in the tools repository under the directory 3rdparty/org.apache.axis/1.4.1.1924.

Links to the vulnerabilities in National Vulnerability database:
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3596

Impact: apache:axis:1.4 and previous versions

Available patch: https://issues.apache.org/jira/secure/attachment/12662672/CVE-2014-3596.patch The proposed patch resolves both vulnerabilities CVE-2012-5784 (AXIS-2883) and CVE-2014-3596.

This patch was applied on org.apache.axis.components.net.JSSESocketFactory.java, the pom.xml in the top repository was modified as follows:
<dependency>
<groupId>com.ca.apm.osgilibs</groupId>
<artifactId>org.apache.axis</artifactId>
- <version>1.4.1.1923</version>
+ <version>1.4.1.1924</version>
</dependency>

As a result of the building (using JDK 1.4.2_13-b06 on top of axis-1.4.jar - size 1599570) the following files were used for the patch 1.4.1.1924:
JSSESocketFactory.class
JSSESocketFactory$Rdn.class
JSSESocketFactory$TypeAndValue.class
MANIFEST.MF 

and org.apache.axis_1.4.1.1924.jar & org.apache.axis_1.4.1.1924.pom were uploaded to the APM Artifactory.

CVE-2018-8032 (MEDIUM) - Apache Web Services Axis 1.4

Vulnerability Description: Apache Axis 1.x up to and including 1.4 is vulnerable to a cross-site scripting (XSS) attack in the default servlet/services.

BD Component Name BD Component Version BD KB Id BD Release Id Vulnerability Severity CVSS Count Files Folder File Name
Apache Web Services Axis 1.4 apache-webservicesaxis 408255 CVE-2018-8032 Medium 5.8 8

mom/product/enterprisemanager/configuration/

org.eclipse.osgi/bundles/31/1/.cp/WebContent/WEB-INF/lib

axis.jar

The following security vulnerability CVE-2018-8032 was reported on Apache Web Services Axis 1.4 for APM 10.7 SP2. 

Unfortunately, there is no direct upgrade path available and Axis2 is not an option (due to the different architecture) so Axis 1.4 is again patched, see details in the tools repository under the directory 3rdparty/org.apache.axis/1.4.1.1927.

Links to the vulnerabilities in National Vulnerability database: https://nvd.nist.gov/vuln/detail/CVE-2018-8032

Impact: apache:axis:1.4 and previous versions

The already patched source file is in `src/org/apache/axis/encoding` directory.

Available patch: CVE-2018-8032.patch

Description: Correctly escape namespace URIs in namespace declarations (CVE-2018-8032)
Origin: backport, https://svn.apache.org/r1831943
--- a/src/org/apache/axis/encoding/SerializationContext.java
+++ b/src/org/apache/axis/encoding/SerializationContext.java
@@ -1176,12 +1176,13 @@
sb.append(':');
sb.append(map.getPrefix());
}
- if ((vecQNames==null) || (vecQNames.indexOf(sb.toString())==-1)) {
+ String qname = sb.toString();
+ if ((vecQNames==null) || (vecQNames.indexOf(qname)==-1)) {
writer.write(' ');
- sb.append("=\"");
- sb.append(map.getNamespaceURI());
- sb.append('"');
- writer.write(sb.toString());
+ writer.write(qname);
+ writer.write("=\"");
+ getEncoder().writeEncoded(writer, map.getNamespaceURI());
+ writer.write('"');
}
}
}

This patch was applied on org.apache.axis.encoding.SerializationContext.java. The final build artifact in APM artifactory is org.apache.axis-1.4.1.1927-10.7-1.jar:

mvn install:install-file "-Dfile=%NEW_AXIS_BUNDLE_JAR%" -DgeneratePom=true -DartifactId=org.apache.axis -DgroupId=com.ca.apm.osgilibs -Dversion=1.4.1.1927-10.7-1 -Dpackaging=jar

The build.xml file is available in the tools repository under the directory 3rdparty/org.apache.axis

CVE-2019-0227 (MEDIUM) - Apache Web Services Axis 1.4

Vulnerability Description: A Server Side Request Forgery (SSRF) vulnerability affected the Apache Axis 1.4 distribution that was last released in 2006. Security and bug commits commits continue in the projects Axis 1.x Subversion repository, legacy users are encouraged to build from source. The successor to Axis 1.x is Axis2, the latest version is 1.7.9 and is not vulnerable to this issue..

BD Component Name BD Component Version BD KB Id BD Release Id Vulnerability Severity CVSS Count Files Folder File Name
Apache Web Services Axis 1.4 apache-webservicesaxis 408255 CVE-2019-0227 Medium 5.4 8

mom/product/enterprisemanager/configuration/org.eclipse.osgi/bundles/98/1/.cp/WebContent/WEB-INF/lib

 

axis.jar

Links to the vulnerabilities in National Vulnerability database: https://nvd.nist.gov/vuln/detail/CVE-2019-0227

The security vulnerability CVE-2019-0227 reported against axis.jar is false positive because the APM Axis1 artifact already does not contain any JWS files or the StockQuoteService default service.

CVE-2017-8046 (HIGH) - Spring Boot 1.4.2

Vulnerability Description: Malicious PATCH requests submitted to servers using Spring Data REST versions prior to 2.6.9 (Ingalls SR9), versions prior to 3.0.1 (Kay SR1) and Spring Boot versions prior to 1.5.9, 2.0 M6 can use specially crafted JSON data to run arbitrary Java code.

BD Component Name BD Component Version BD KB Id BD Release Id Vulnerability Severity CVSS Count Files Folder File Name
Spring Boot 1.4.2 springboot1917535 7032859 CVE-2017-8046 High 7.5 14 APMCommandCenterServer/lib/acc-configserver-ui.war/WEB-INF/lib spring-boot-starter-websocket-1.4.2.RELEASE.jar

APM Command Center uses both spring-data-rest-core*.jar spring-data-rest-webmvc*.jar. These libraries contain the vulnerability in versions that do not contains the fix disclosed at https://jira.spring.io/browse/DATAREST-1127

APM Command Center 10.7 GA contains versions that are fixed: spring-data-rest-core-2.5.12.ca-007c450.jar, spring-data-rest-webmvc-2.5.12.ca-007c450.jar

Some service packs of APM Command Center 10.7 contain spring-data-rest-core-2.6.17.RELEASE.jar, spring-data-rest-webmvc-2.6.17.RELEASE.jar which also contain the fix.

"Spring Boot" as a whole is not vulnerable directly. As part of Spring Boot there is a library which defines a set of libraries that are recommended to use.
For Spring Boot 1.4.2.RELEASE this part called (in format of Maven artifact, e.h. group_id:artifact_id:version):
org.springframework.boot:spring-boot-dependencies:1.4.2.RELEASE
this one defines what version of spring data is recommended in its file spring-boot-dependencies-1.4.2.RELEASE.pom:
             <spring-data-releasetrain.version>Hopper-SR5</spring-data-releasetrain.version>

This org.springframework.data:spring-data-releasetrain:Hopper-SR5 declares dependency on vulnerable version of Spring Data REST (in spring-data-releasetrain-Hopper-SR5.pom):
             <!-- Spring Data REST -->
             <dependency>
                          <groupId>org.springframework.data</groupId>
                          <artifactId>spring-data-rest-webmvc</artifactId>
                          <version>2.5.5.RELEASE</version>
             </dependency>
             <dependency>
                          <groupId>org.springframework.data</groupId>
                          <artifactId>spring-data-rest-core</artifactId>
                          <version>2.5.5.RELEASE</version>
             </dependency>

The Black Duck software identified spring-boot-starter-websocket-1.4.2.RELEASE.jar as vulnerable. That file is not vulnerable. But vulnerable dependency is reachable through it, in this way:

spring-boot-starter-websocket-1.4.2.RELEASE.jar depends org.springframework.boot:spring-boot-starters:1.4.2.RELEASE.jar through parent relationship which depends on org.springframework.boot:spring-boot-parent:1.4.2.RELEASE.jar which depends on org.springframework.boot:spring-boot-dependencies:1.4.2.RELEASE.jar through parent relationship which contains property definition:
             <spring-data-releasetrain.version>Hopper-SR5</spring-data-releasetrain.version>

That does not mean that much as this property can be changed or dependencies can be changed to different version when they are used.

So mere presence of spring-boot-starter-websocket-1.4.2.RELEASE.jar does not imply the vulnerability is there, even though it is more likely. The real test for vulnerability is presence of spring-data-rest-core*.jar spring-data-rest-webmvc*.jar

CVE-2016-5007, CVE-2018-1258 (MEDIUM) - spring-framework 3.2.18.RELEASE

Vulnerability Description: Both Spring Security 3.2.x, 4.0.x, 4.1.0 and the Spring Framework 3.2.x, 4.0.x, 4.1.x, 4.2.x rely on URL pattern mappings for authorization and for mapping requests to controllers respectively. Differences in the strictness of the pattern matching mechanisms, for example with regards to space trimming in path segments, can lead Spring Security to not recognize certain paths as not protected that are in fact mapped to Spring MVC controllers that should be protected. The problem is compounded by the fact that the Spring Framework provides richer features with regards to pattern matching as well as by the fact that pattern matching in each Spring Security and the Spring Framework can easily be customized creating additional differences.Spring Framework version 5.0.5 when used in combination with any versions of Spring Security contains an authorization bypass when using method security. An unauthorized malicious user can gain unauthorized access to methods that should be restricted.

BD Component Name BD Component Version BD KB Id BD Release Id Vulnerability Severity CVSS Count Files Folder File Name
spring-framework 3.2.18.RELEASE springframework1869467 7216456 CVE-2016-5007, CVE-2018-1258 Medium 5.0, 6.5 2

mom/product/enterprisemanager/

configuration/org.eclipse.osgi/

bundles/186/1/.cp/lib

spring-aspects-3.2.18.RELEASE.jar

Spring-aspects-3.2.18.RELEASE.jar (CVE-2016-5007, CVE-2018-1258) is also false positive in APM 10.7. Based on the source code inspection (CVE-2016-5007) we can say that we do not use AntPathMatcher directly neither do we use it indirectly through HttpSecurity.antMatchers() in either Enterprise Manager or WebView. We do not use MvcRequestMatcher either. This issue does not affect MvcRequestMatcher at all. Here is a quote from Pivotal’s page regarding CVE-2016-5007 that mentions MvcRequestMatcher:

As for CVE-2018-1258, the bug is present only in Spring Framework 5.0.5.RELEASE. APM does not use Spring Framework 5.0.5.RELEASE so it is not impacted. The bug does not impact any Spring Framework 4.x versions or any other versions of Spring Framework.

CVE-2019-3778 (MEDIUM) - spring-security-oauth2-2.0.16.RELEASE.jar

Vulnerability Description: Spring Security OAuth, versions 2.3 prior to 2.3.5, and 2.2 prior to 2.2.4, and 2.1 prior to 2.1.4, and 2.0 prior to 2.0.17, and older unsupported versions could be susceptible to an open redirector attack that can leak an authorization code. A malicious user or attacker can craft a request to the authorization endpoint using the authorization code grant type, and specify a manipulated redirection URI via the "redirect_uri" parameter. This can cause the authorization server to redirect the resource owner user-agent to a URI under the control of the attacker with the leaked authorization code. This vulnerability exposes applications that meet all of the following requirements: Act in the role of an Authorization Server (e.g. @EnableAuthorizationServer) and uses the DefaultRedirectResolver in the AuthorizationEndpoint. This vulnerability does not expose applications that: Act in the role of an Authorization Server and uses a different RedirectResolver implementation other than DefaultRedirectResolver, act in the role of a Resource Server only (e.g. @EnableResourceServer), act in the role of a Client only (e.g. @EnableOAuthClient).

BD Component Name BD Component Version BD KB Id BD Release Id Vulnerability Severity CVSS Count Files Folder File Name
OAuth2 for Spring Security 2.0.16.RELEASE     CVE-2019-3778 Medium 6.4 1

bdscan/APMCommandCenterServer.tar.gz/ APMCommandCenterServer/lib/acc-configserver-ui.war/WEB-INF/lib

 

spring-security-oauth2-2.0.16.RELEASE.jar

In https://nvd.nist.gov/vuln/detail/CVE-2019-3778

This vulnerability exposes applications that meet all of the following requirements: Act in the role of an Authorization Server (e.g. @EnableAuthorizationServer) and uses the DefaultRedirectResolver in the AuthorizationEndpoint. This vulnerability does not expose applications that: Act in the role of an Authorization Server and uses a different RedirectResolver implementation other than DefaultRedirectResolver, act in the role of a Resource Server only (e.g. @EnableResourceServer), act in the role of a Client only (e.g. @EnableOAuthClient).

ACC Config Server only uses this OAuth2 library through @EnableResourceServer only so according to the description ACC Config Server is not impacted by this vulnerability.

CVE-2018-10237 (MEDIUM - agent jars) - Guava 

Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable.

This vulnerability can be fixed by upgrading the Guava version to 24.1.1. But that breaks the Java compatibility for Java 6 & 7 since 24.1.1 only supports Java 8. In addition the Guava library that the agent uses, is loaded by our own custom class loader and hence won't be accessible by the application. So the application, if they have to use some utilities from the Guava library, has to use its own copy/version where the CVE's have been addressed. The agent uses only a subset of the classes which can not be exploited other than the intended use by the agent.

CVE-2020-8908 (BDSA-2020-3736) (LOW - agent jars) - Guava 

 

BD Component Name BD Component Version BD KB Id BD Release Id Vulnerability Severity CVSS Count Files Folder File Name
Guava: Google Core Libraries for Java 19.0     CVE-2020-8908 LOW   1

/wily/core/ext/lib/guava.jar

 

guava.jar

In https://nvd.nist.gov/vuln/detail/CVE-2020-8908 (BDSA-2020-3736)

A temp directory creation vulnerability exist in Guava versions prior to 30.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava com.google.common.io.Files.createTempDir(). The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. We recommend updating Guava to version 30.0 or later, or update to Java 7 or later, or to explicitly change the permissions after the creation of the directory if neither are possible.

This vulnerability can be fixed by upgrading the Guava version to 24.1.1. But that breaks the Java compatibility for Java 6 & 7 since 24.1.1 only supports Java 8. In addition the Guava library that the agent uses, is loaded by our own custom class loader and hence won't be accessible by the application. So the application, if they have to use some utilities from the Guava library, has to use its own copy/version where the CVE's have been addressed. The agent uses only a subset of the classes which can not be exploited other than the intended use by the agent.

CVE-2018-1313 (BDSA-2018-1426) (MEDIUM - agent jars) - Apache Derby

 

BD Component Name BD Component Version BD KB Id BD Release Id Vulnerability Severity CVSS Count Files Folder File Name
Apache Derby 10.12.1.1     CVE-2018-1313 (BDSA-2018-1426) MEDIUM   2

/wily/core/ext/DynInstrSupport15.jar

 

DynInstrSupport15.jar

In https://nvd.nist.gov/vuln/detail/CVE-2018-1313 (BDSA-2018-1426)

In Apache Derby 10.3.1.4 to 10.14.1.0, a specially-crafted network packet can be used to request the Derby Network Server to boot a database whose location and contents are under the user's control. If the Derby Network Server is not running with a Java Security Manager policy file, the attack is successful. If the server is using a policy file, the policy file must permit the database location to be read for the attack to work. The default Derby Network Server policy file distributed with the affected releases includes a permissive policy as the default Network Server policy, which allows the attack to work

With UI based dynamic instrumentation gonem, we no longer make use of Derby, so that is not a real vulnerability. So this can be marked as a false positive in security scans. 

CVE-2018-11771 (MEDIUM - agent jars) - commons-compress

When reading a specially crafted ZIP archive, the read method of Apache Commons Compress 1.7 to 1.17's ZipArchiveInputStream can fail to return the correct EOF indication after the end of the stream has been reached. When combined with a java.io.InputStreamReader this can lead to an infinite stream, which can be used to mount a denial of service attack against services that use Compress' zip package.

This vulnerability exposes a risk of unzipping thirdparty products. Usage of commons-compress in Agent code only unzips archives that are part of our product. We do not unzip any archives that are received from outside sources. So this vulnerability does not apply to Agent and can be marked as a false positive.

CVE-2020-1938 (CRITICAL) - cpe:2.3:a:apache:tomcat (aka Ghostcat)

Vulnerability Description: When using the Apache JServ Protocol (AJP), care must be taken when trusting incoming connections to Apache Tomcat. Tomcat treats AJP connections as having higher trust than, for example, a similar HTTP connection. If such connections are available to an attacker, they can be exploited in ways that may be surprising. In Apache Tomcat 9.0.0.M1 to 9.0.0.30, 8.5.0 to 8.5.50 and 7.0.0 to 7.0.99, Tomcat shipped with an AJP Connector enabled by default that listened on all configured IP addresses. It was expected (and recommended in the security guide) that this Connector would be disabled if not required. This vulnerability report identified a mechanism that allowed: - returning arbitrary files from anywhere in the web application - processing any file in the web application as a JSP Further, if the web application allowed file upload and stored those files within the web application (or the attacker was able to control the content of the web application by some other means) then this, along with the ability to process a file as a JSP, made remote code execution possible. It is important to note that mitigation is only required if an AJP port is accessible to untrusted users. Users wishing to take a defence-in-depth approach and block the vector that permits returning arbitrary files and execution as JSP may upgrade to Apache Tomcat 9.0.31, 8.5.51 or 7.0.100 or later. A number of changes were made to the default AJP Connector configuration in 9.0.31 to harden the default configuration. It is likely that users upgrading to 9.0.31, 8.5.51 or 7.0.100 or later will need to make small changes to their configurations.

This is a false positive because Apache Tomcat is not shipped with the APM 10.7 product but we only use org.mortbay.jasper:apache-jsp from the whole Apache Tomcat. You can see org.mortbay.jasper:apache-jsp dependency from the OWASP dependency check.

apache-jsp-8.5.49.jar (pkg:maven/org.mortbay.jasper/[email protected], cpe:2.3:a:apache:tomcat:8.5.49:*:*:*:*:*:*:*, cpe:2.3:a:apache_software_foundation:tomcat:8.5.49:*:*:*:*:*:*:*)

But the apache-jsp is not the whole Tomcat. The CVE-2020-1938 vulnerability is about the AJP connector in Tomcat but our dependency is only related to the JSP engine. Therefore, it is a false positive.

In the past, we performed the negative test for the following HIGH CVEs: CVE-2005-4836, CVE-2006-7197, CVE-2009-3548, CVE-2011-3190, Apache Tomcat  5.5.15. The Black Duck Protex scan on two 3rd party libraries: jasper-compiler-jdt-5.5.15.jar & jasper-runtime-5.5.15.jar under the project com.wily.introscope.jetty revealed that both libraries were reported as

Component: Apache Tomcat

Version: 5.5.15

Home Page: http://jakarta.apache.org/tomcat/index.html

License: Apache License 2.0

External IDs: mvn:tomcat:jasper-compiler-jdt:jar:5.5.15, mvn:tomcat:jasper-runtime:jar:5.5.15

Usage: Component

The next scan of the fresh APM 10.3 deployment without both libraries jasper-compiler-jdt-5.5.15.jar & jasper-runtime-5.5.15.jar revealed no Apache Tomcats (project com.wily.introscope.jetty-jasper). Furthermore, no org.apache.jasper or org.eclipse.jdt imports were found in our source code. The jasper-compiler-jdt-5.5.15.jar & jasper-runtime-5.5.15.jar libraries are shipped inside org.mortbay.jetty-6.1.26.jar and used for compiling .jsp files into Java classes only. So vulnerability issues CVE-2005-4836 (HTTP/1.1 connector in Tomcat & incorrect length for chunks), CVE-2006-7197 (AJP protocol & also incorrect length for chunks), CVE-2009-3548 (Tomcat installer & blank default password for the administrative user), CVE-2011-3190 (AJP requests, bypass authentication) are also a false positive.

CVE-2021-30639 (HIGH) - Tomcat libraries

Vulnerability Description: A vulnerability in Apache Tomcat allows an attacker to remotely trigger a denial of service. An error introduced as part of a change to improve error handling during non-blocking I/O meant that the error flag associated with the Request object was not reset between requests. This meant that once a non-blocking I/O error occurred, all future requests handled by that request object would fail. Users were able to trigger non-blocking I/O errors, e.g. by dropping a connection, thereby creating the possibility of triggering a DoS. Applications that do not use non-blocking I/O are not exposed to this vulnerability. This issue affects Apache Tomcat 10.0.3 to 10.0.4; 9.0.44; 8.5.64.

This is a false positive because Apache Tomcat is not shipped with the APM 10.7 product but we only use org.mortbay.jasper:apache-jsp from the whole Apache Tomcat. You can see org.mortbay.jasper:apache-jsp dependency from the OWASP dependency check or in the BlackDuck scan. The CVE-2021-30639 vulnerability is about the remote trigger a denial of service but our dependency is only related to the JSP engine. You can perform a negative test described in the section related to CVE-2020-1938 above.

CVE-2021-30640 (MEDIUM) - Tomcat libraries

Vulnerability Description: A vulnerability in the JNDI Realm of Apache Tomcat allows an attacker to authenticate using variations of a valid user name and/or to bypass some of the protection provided by the LockOut Realm. This issue affects Apache Tomcat 10.0.0-M1 to 10.0.5; 9.0.0.M1 to 9.0.45; 8.5.0 to 8.5.65.

This is a false positive because Apache Tomcat is not shipped with the APM 10.7 product but we only use org.mortbay.jasper:apache-jsp from the whole Apache Tomcat. You can see org.mortbay.jasper:apache-jsp dependency from the OWASP dependency check or in the BlackDuck scan. The CVE-2021-30640 vulnerability is about the authentication using variations of a valid user name (see above) but our dependency is only related to the JSP engine. You can perform a negative test described in the section related to CVE-2020-1938 above.

CVE-2021-41079 (HIGH) - Tomcat libraries

Vulnerability Description: Apache Tomcat 8.5.0 to 8.5.63, 9.0.0-M1 to 9.0.43 and 10.0.0-M1 to 10.0.2 did not properly validate incoming TLS packets. When Tomcat was configured to use NIO+OpenSSL or NIO2+OpenSSL for TLS, a specially crafted packet could be used to trigger an infinite loop resulting in a denial of service.

This is a false positive because Apache Tomcat is not shipped with the APM 10.7 product but we only use org.mortbay.jasper:apache-jsp from the whole Apache Tomcat. You can see org.mortbay.jasper:apache-jsp dependency from the OWASP dependency check or in the BlackDuck scan. The CVE-2021-41079 vulnerability is about not proper validation of incoming TLS packets but our dependency is only related to the JSP engine. You can perform a negative test described in the section related to CVE-2020-1938 above.

CVE-2014-0114 (HIGH) (struts ActionForm object) Apache Struts 1.x-1.3.10, 2.x-2.3.16.2

Vulnerability Description: Apache Commons BeanUtils, as distributed in lib/commons-beanutils-1.8.0.jar in Apache Struts 1.x through 1.3.10 and in other products requiring commons-beanutils through 1.9.2, does not suppress the class property, which allows remote attackers to "manipulate" the ClassLoader and execute arbitrary code via the class parameter, as demonstrated by the passing of this parameter to the getClass method of the ActionForm object in Struts 1.

This is a false positive because:

1) The main focus of this CVE is related to Struts1 library and the ActionForm class. The source code repository scan shows that none of the Java classes is using the ActionForm class or any source code from the Struts library.

2) Struts1 library is not used in any of application repositories. It is only referenced inside the .pbd class notations which is not executable code.

3) Beanutils is only addressed directly in one class (CC related) that is calling the .setProperty method which is not in affected by this CVE.

For more information see exploit for this particular CVE.

CVE-2019-10086 (HIGH) - org.apache.commons_beanutils-1.9.3.jar

Vulnerability Description: In Apache Commons Beanutils 1.9.2, a special BeanIntrospector class was added which allows suppressing the ability for an attacker to access the classloader via the class property available on all Java objects. 

This is a false positive because the PropertyUtilsBean class is not used in the APM product. This particular CVE applies only when BeanIntrospector is used which utilizes the PropertyUtilsBean class. See Proof of concept for more details.

CVE-2014-1904 (MEDIUM) (Formtag) Spring Framework 3.0.0-3.2.8, 4.0.0-4.0.2

Vulnerability Description: Cross-site scripting (XSS) vulnerability in web/servlet/tags/form/FormTag.java in Spring MVC in Spring Framework 3.0.0 before 3.2.8 and 4.0.0 before 4.0.2 allows remote attackers to inject arbitrary web script or HTML via the requested URI in a default action.

This is a false positive because the vulnerability exploits class Formtag.java, used Spring Form only. Our APM product does not use the Spring Framework Form feature. This class is not addressed anywhere. For more information see commits that address this particular CVE: 1 and 2

CVE-2014-0054 (MEDIUM) (Jaxb2RootElementHttpMessageConverter) Spring 3.0.0-3.2.7, 4.0.0-4.0.1

Vulnerability Description: Spring MVC's Jaxb2RootElementHttpMessageConverter also processed user provided XML and neither disabled XML external entities nor provided an option to disable them. Jaxb2RootElementHttpMessageConverter has been modified to provide an option to control the processing of XML external entities and that processing is now disabled by default.

This is a false positive because this CVE is related to the specific class Jaxb2RootElementHttpMessageConverter that we are not using anywhere in our code. For more information see commit that address this particular CVE.

CVE-2015-3192 (MEDIUM) (XML bomb) Spring Framework 3.x-3.2.1, 4.x - 4.1.7

Vulnerability Description: Pivotal Spring Framework before 3.2.14 and 4.x before 4.1.7 do not properly process inline DTD declarations when DTD is not entirely disabled, which allows remote attackers to cause a denial of service (memory consumption and out-of-memory errors) via a crafted XML file.

This vulnerability can be mitigated by setting:
* disallow-doctype-dec feature in the DOM and SAX APIs to true
* supportDTD property in the StAX API to false.

For more information on configuration see.

CVE-2018-1270 (CRITICAL) (Stomp message protocol)  Spring Framework 5.0 to 5.0.4, 4.3-4.3.15   
CVE-2018-1275 (CRITICAL) (Stomp message protocol) All the Same

Vulnerability Description: Spring Framework, versions 5.0.x prior to 5.0.5 and versions 4.3.x prior to 4.3.16, and older unsupported versions allow applications to expose STOMP over WebSocket endpoints with a simple, in-memory STOMP broker through the spring-messaging module. A malicious user (or attacker) can craft a message to the broker that can lead to a remote code execution attack.

This is a false positive because we are not using Stomp over Websocket in any location of our code. For more information on configuration see STOMP enabling / configuration example code.

CVE-2013-6429 (MEDIUM) (SourceHttpMessageConverter) Spring MVC 3.x-3.2.8, 4.x-4.0.2

Vulnerability Description: Spring MVC's SourceHttpMessageConverter also processed user provided XML and neither disabled XML external entities nor provided an option to disable them. SourceHttpMessageConverter has been modified to provide an option to control the processing of XML external entities and that processing is now disabled by default. It was subsequently discovered that this fix was also incomplete (CVE-2014-0054).

This is a false positive because neither SourceHttpMessageConverter nor StaxUtils is used in our code. For more information see commits that address this particular CVE: 

CVE-2018-1272 (MEDIUM) (Multipart Requests) Spring Framework 5.0 - 5.0.4, 4.3-4.3.14

Vulnerability Description: Spring Framework versions 5.0 to 5.0.4, 4.3 to 4.3.14, and older unsupported versions provide client-side support for multipart requests. When Spring MVC or Spring WebFlux server application (server A) receives input from a remote client, and then uses that input to make a multipart request to another server (server B), it can be exposed to an attack, where an extra multipart is inserted in the content of the request from server A, causing server B to use the wrong value for a part it expects. This could to lead privilege escalation, for example, if the part content represents a username or user roles.

This is a false positive because files that are exploited for this particular CVE does not exist with a release version 3.2.18 ( MimeTypeUtils.java ).

For more information see commits that address this particular CVE. 

SPR-7779 (LocaleChangeInterceptor) Spring Framework 3.x-3.0.6

Vulnerability Description: The current implementation of the LocaleChangeInterceptor does not an escaping of the value from the request. This can lead to a XSS issue.

This is a false positive because we are not using LocaleChangeInterceptor anywhere in our code. See issue description for more info.

CVE-2019-10086 (HIGH) (BeanIntrospector) Apache Commons Beanutils 1.9.2

Vulnerability Description: In Apache Commons Beanutils 1.9.2, a special BeanIntrospector class was added which allows suppressing the ability for an attacker to access the classloader via the class property available on all Java objects. We, however were not using this by default characteristic of the PropertyUtilsBean.

This is a false positive because we are not using BeanIntrospector class anywhere in our code.

CVE-2014-0225 (HIGH) Spring Framework 4.0.0 to 4.0.4, 3.0.0 to 3.2.8, XXE attack

Vulnerability Description: When processing user provided XML documents, the Spring Framework 4.0.0 to 4.0.4, 3.0.0 to 3.2.8, and possibly earlier unsupported versions did not disable by default the resolution of URI references in a DTD declaration. This enabled an XXE attack.

This is a false positive. The issue was fixed on version 3.2.8 (our library version is 3.2.18). Commits that were applied to fix this exploit are already present in current distribution. See commits for more details.

CVE-2014-3578 (MEDIUM) Spring Framework 3.x before 3.2.9 and 4.0 before 4.0.5

Vulnerability Description: Directory traversal vulnerability in Pivotal Spring Framework 3.x before 3.2.9 and 4.0 before 4.0.5 allows remote attackers to read arbitrary files via a crafted URL.

This is a false positive. The issue was fixed on version 3.2.9 (our library version is 3.2.18). Commits that were applied to fix this exploit are already present in current distribution. See commits for more details. 

CVE-2017-5638 (CRITICAL) Apache Struts 2 2.3.x before 2.3.32 and 2.5.x before 2.5.10.1

Vulnerability Description: The Jakarta Multipart parser in Apache Struts 2 2.3.x before 2.3.32 and 2.5.x before 2.5.10.1 has incorrect exception handling and error-message generation during file-upload attempts, which allows remote attackers to execute arbitrary commands via a crafted Content-Type, Content-Disposition, or Content-Length HTTP header, as exploited in the wild in March 2017 with a Content-Type header containing a #cmd= string.

This is a false positive. The CVE is reported in Struts 2 class FileUploadInterceptor.java. It uses LocalizedTextUtil.java to display error message during upload failure. These two classes are part of struts 2 framework and not available in strut 1 framework. Above mentioned classes(FileUploadInterceptor.java,LocalizedTextUtil.java) are not part of any of these binaries. We are only using Struts-menu 2.3 library(though v2.3) which is an independent library which can be used with plain JSPs to display menus in client side.

See commits that fixes this issue for more details.

CVE-2017-5638 (HIGH) Apache Struts 2.1.1 through 2.3.x before 2.3.34 and 2.5.x before 2.5.13

Vulnerability Description: The REST Plugin in Apache Struts 2.1.1 through 2.3.x before 2.3.34 and 2.5.x before 2.5.13 uses an XStreamHandler with an instance of XStream for deserialization without any type filtering, which can lead to Remote Code Execution when deserializing XML payloads.

This is a false positive. Above mentioned classes are not part of any of these binaries. We are only using Struts-menu 2.3 library(though v2.3) which is an independent library which can be used with plain JSPs to display menus in client side.

See commits that fixes this issue for more details.

CVE-2020-27216 (HIGH) - Jetty Temp Files

Vulnerability Description: In Eclipse Jetty versions 1.0 thru 9.4.32.v20200930, 10.0.0.alpha1 thru 10.0.0.beta2, and 11.0.0.alpha1 thru 11.0.0.beta2O, on Unix like systems, the system's temporary directory is shared between all users on that system. A collocated user can observe the process of creating a temporary sub directory in the shared temporary directory and race to complete the creation of the temporary subdirectory. If the attacker wins the race then they will have read and write permission to the subdirectory used to unpack web applications, including their WEB-INF/lib jar files and JSP files. If any code is ever executed out of this temporary directory, this can lead to a local privilege escalation vulnerability..

This is a false positive. Both EM & WebView are using ./work folder inside Introscope directory as a temporary folder.

CVE-2019-11358 (MEDIUM)  - docker-utility-2.0.25.jar: jquery-3.1.1.min.js

CVE-2020-11022 (MEDIUM)  - docker-utility-2.0.25.jar: jquery-3.1.1.min.js

CVE-2020-11023 (MEDIUM) - docker-utility-2.0.25.jar: jquery-3.1.1.min.js

Vulnerability Description: 

  1. jQuery before 3.4.0, as used in Drupal, Backdrop CMS, and other products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype pollution. If an unsanitized source object contained an enumerable __proto__ property, it could extend the native Object.prototype.
  2. In jQuery versions greater than or equal to 1.2 and before 3.5.0, passing HTML from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code. This problem is patched in jQuery 3.5.0.
  3. In jQuery versions greater than or equal to 1.0.3 and before 3.5.0, passing HTML containing <option> elements from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code. This problem is patched in jQuery 3.5.0.

This is false positive because in APM (UMA) we are not using jquery script. APM uses only some helper java classes , to get container flow data, available in docker-utility jar.

CVE-2017-12629 (CRITICAL) - Apache Lucene 4.7.2

Vulnerability Description: Remote code execution occurs in Apache Solr before 7.1 with Apache Lucene before 7.1 by exploiting XXE in conjunction with use of a Config API add-listener command to reach the RunExecutableListener class. Elasticsearch, although it uses Lucene, is NOT vulnerable to this. Note that the XML external entity expansion vulnerability occurs in the XML Query Parser which is available, by default, for any query request with parameters deftype=xmlparser and can be exploited to upload malicious data to the /upload request handler or as Blind XXE using ftp wrapper in order to read arbitrary local files from the Solr server. Note also that the second vulnerability relates to remote code execution using the RunExecutableListener available on all affected versions of Solr.

This is false positive because we do not use solr library anywhere in our code.

CVE-2017-9096 (HIGH) - iText 1.3.1, 2.1.3, 2.0.7

Vulnerability Description: The XML parsers in iText before 5.5.12 and 7.x before 7.0.3 do not disable external entities, which might allow remote attackers to conduct XML external entity (XXE) attacks via a crafted PDF.

This is false positive because the templates for JasperReports are stored in a JAR file and cannot be modified by the user or an attacker.

CVE-2021-43113 (CRITICAL) - iText command injection via a CompareTool filename

Vulnerability Description: iTextPDF in iText before 7.1.17 allows command injection via a CompareTool filename that is mishandled on the gs (aka Ghostscript) command line in GhostscriptHelper.java

The APM product is not vulnerable to this CVE. APM is not using CompareTool class and the filename is also not provided as input from the user or any other service.

CVE-2017-16853 (HIGH) - OpenSAML before 2.6.1

Vulnerability Description: The DynamicMetadataProvider class in saml/saml2/metadata/impl/DynamicMetadataProvider.cpp in OpenSAML-C in OpenSAML before 2.6.1 fails to properly configure itself with the MetadataFilter plugins and does not perform critical security checks such as signature verification, enforcement of validity periods, and other checks specific to deployments, aka CPPOST-105.

This is false positive because the artefact version mentioned in the BlackDuck scan is 2.6.6 but https://nvd.nist.gov/vuln/detail/CVE-2017-16853 says the vulnerability is up to and excluding 2.6.1. The BlackDuck tool fails to detect the version correctly in the scan.

CVE-2021-41616 (CRITICAL) - Apache Hive

Vulnerability Description: Apache DB DdlUtils 1.0 included a BinaryObjectsHelper that was intended for use when migrating database data with a SQL data type of BINARY, VARBINARY, LONGVARBINARY, or BLOB between databases using the ddlutils features. The BinaryObjectsHelper class was insecure and used ObjectInputStream.readObject without validating that the input data was safe to deserialize. Please note that DdlUtils is no longer being actively developed. To address the insecurity of the BinaryObjectHelper class, the following changes to DdlUtils have been made: (1) BinaryObjectsHelper.java has been deleted from the DdlUtils source repository and the DdlUtils feature of propagating data of SQL binary types is therefore no longer present in DdlUtils; (2) The ddlutils-1.0 release has been removed from the Apache Release Distribution Infrastructure; (3) The DdlUtils web site has been updated to indicate that DdlUtils is now available only as source code, not as a packaged release.

This is false positive. We analyzed our jfreechart library from 10.7. It contains jcommon-1.0.12.jar and jfreechart-1.0.9.jar and there is no BinaryObjectsHelper.class We don't use DdlUtils, the library is not even in our artifactory. We also looked at the sources of DdlUtils and the BinaryObjectsHelper class is used only in the version 1.0. There is no chance of vulnerability via CVE-2021-41616 in the APM 10.7.

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-2021-43557 (HIGH) - Apache Hive

Vulnerability Description: The uri-block plugin in Apache APISIX before 2.10.2 uses $request_uri without verification. The $request_uri is the full original request URI without normalization. This makes it possible to construct a URI to bypass the block list on some occasions. For instance, when the block list contains "^/internal/", a URI like `//internal/` can be used to bypass it. Some other plugins also have the same issue. And it may affect the developer's custom plugin.

We checked the com.wily.ui.jfree.chart library and the libraries inside the "lib" subdirectory (jcommon-1.0.12.jar and jfreechart-1.0.9.jar). We also looked at the usage of these libraries and they are only used for drawing charts. There is nothing related to "Apache Hive" or the URI manipulation or the Apache APISIX Dashboard. Therefore, this vulnerability is a false positive.

CVE-2021-45232, CVE-2022-24112 (CRITICAL) - Apache Hive

Vulnerability Description: In Apache APISIX Dashboard before 2.10.1, the Manager API uses two frameworks and introduces framework `droplet` on the basis of framework `gin`, all APIs and authentication middleware are developed based on framework `droplet`, but some API directly use the interface of framework `gin` thus bypassing the authentication.

An attacker can abuse the batch-requests plugin to send requests to bypass the IP restriction of Admin API. A default configuration of Apache APISIX (with default API key) is vulnerable to remote code execution. When the admin key was changed or the port of Admin API was changed to a port different from the data panel, the impact is lower. But there is still a risk to bypass the IP restriction of Apache APISIX's data panel. There is a check in the batch-requests plugin which overrides the client IP with its real remote IP. But due to a bug in the code, this check can be bypassed.

We checked the com.wily.ui.jfree.chart library and the libraries inside the "lib" subdirectory (jcommon-1.0.12.jar and jfreechart-1.0.9.jar). We also looked at the usage of these libraries and they are only used for drawing charts. There is nothing related to "Apache Hive" or the URI manipulation or the Apache APISIX Dashboard. Therefore, these vulnerabilities are false positive.

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 EM and VW I see that it is using java 8, so not 9+.

Both APM 10.7 and 10.8 use Java 8 so they are not vulnerable now. At some point there is a switch to 11 planned but that can happen with a switch to newer spring 5.3.18 that contains the fix.

CVE-2022-24197 (MEDIUM) - iText v7.1.17

Vulnerability Description: iText v7.1.17 was discovered to contain a stack-based buffer overflow via the component ByteBuffer.append, which allows attackers to cause a Denial of Service (DoS) via a crafted PDF file.

This security vulnerability is about the attacker supplied PDF. We do not use iText to read PDFs. Therefore, it is false positive.

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: 7u331, 8u321, 11.0.14 (*); 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 10.7/10.8 server itself directly:

  • APM 10.7 and 10.8 server does not use affected java version.

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 / ACC Controller configured for validating certificates and running on affected java runtime. Java version is out of control of APM here except for ACC 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. 

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 HTTP invoker functionality anywhere.

CVE-2022-25757, CVE-2022-29266 (HIGH, CRITICAL) - Apache Hive

Vulnerability Description: In Apache APISIX before 2.13.0, when decoding JSON with duplicate keys, lua-cjson will choose the last occurred value as the result. By passing a JSON with a duplicate key, the attacker can bypass the body_schema validation in the request-validation plugin. For example, `{"string_payload":"bad","string_payload":"good"}` can be used to hide the "bad" input. Systems satisfy three conditions below are affected by this attack: 1. use body_schema validation in the request-validation plugin 2. upstream application uses a special JSON library that chooses the first occurred value, like jsoniter or gojay 3. upstream application does not validate the input anymore. The fix in APISIX is to re-encode the validated JSON input back into the request body at the side of APISIX. Improper Input Validation vulnerability in __COMPONENT__ of Apache APISIX allows an attacker to __IMPACT__. This issue affects Apache APISIX Apache APISIX version 2.12.1 and prior versions.

In APache APISIX before 3.13.1, the jwt-auth plugin has a security issue that leaks the user's secret key because the error message returned from the dependency lua-resty-jwt contains sensitive information.

APM uses the com.wily.ui.jfree.chart library (only used for drawing charts). Apache Hive is a transitive dependency. We are not aware of using any mentioned functions in the reported CVEs.

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 so the APM 10.8 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.

In APM 10.7 and 10.8 the library is contained in the installer and ConfigUtility, but it is not used (a transitive dependency induced by commons-configuration2).