Fixed Common Vulnerabilities and Exposures in Cloudera Flow Management in 4.11.0

The SslHandler in Netty before 3.9.2 allows remote attackers to cause a denial of service (infinite loop and CPU consumption) via a crafted SSLv2Hello message.

Netty before 3.9.8.Final, 3.10.x before 3.10.3.Final, 4.0.x before 4.0.28.Final, and 4.1.x before 4.1.0.Beta5 and Play Framework 2.x before 2.3.9 might allow remote attackers to bypass the httpOnly flag on cookies and obtain sensitive information by leveraging improper validation of cookie name and value characters.

In Apache Hadoop 2.x before 2.7.4, a user who can escalate to yarn user can possibly run arbitrary commands as root user.

Vulnerability in Apache Hadoop 0.23.x, 2.x before 2.7.5, 2.8.x before 2.8.3, and 3.0.0-alpha through 3.0.0-beta1 allows a cluster user to expose private files owned by the user running the MapReduce job history server process.

The malicious user can construct a configuration file containing XML directives that reference sensitive files on the MapReduce job history server host.

The Alias feature in SnakeYAML before 1.26 allows entity expansion during a load operation, a related issue to CVE-2003-1564.

The HDFS web Ul in Apache Hadoop before 2.7.0 is vulnerable to a cross-site scripting (XSS) attack through an unescaped query parameter.

HDFS clients interact with a servlet on the DataNode to browse the HDFS namespace. The NameNode is provided as a query parameter that is not validated in Apache Hadoop before 2.7.0.

In Apache Hadoop 3.1.0 to 3.1.1, 3.0.0-alpha1 to 3.0.3, 2.9.0 to 2.9.1, and 2.0.0-alpha to 2.8.4, the user/group information can be corrupted across storing in fsimage and reading back from fsimage.

In Apache Hadoop versions 3.0.0-alpha1 to 3.1.0, 2.9.0 to 2.9.1, and 2.2.0 to 2.8.4, a user who can escalate to yarn user can possibly run arbitrary commands as root user.

Netty before 4.1.42.Final mishandles whitespace before the colon in HTTP headers (such as a "Transfer-Encoding: chunked" line), which leads to HTTP request smuggling.

HttpObjectDecoder.java in Netty before 4.1.44 allows an HTTP header that lacks a colon, which might be interpreted as a separate header with an incorrect syntax, or might be interpreted as an "invalid fold."

HttpObjectDecoder.java in Netty before 4.1.44 allows a Content-Length header to be accompanied by a second Content-Length header, or by a Transfer-Encoding header.

The ZlibDecoders in Netty 4.1.x before 4.1.46 allow for unbounded memory allocation while decoding a ZlibEncoded byte stream.

An attacker could send a large ZlibEncoded byte stream to the Netty server, forcing the server to allocate all of its free memory to a single decoder.

Couchbase Server Java SDK before 2.7.1.1 allows a potential attacker to forge an SSL certificate and pose as the intended peer.

An attacker can leverage this flaw by crafting a cryptographically valid certificate that will be accepted by Java SDK's Netty component due to missing hostname verification.

In verifyHostName of OkHostnameVerifier.java, there is a possible way to accept a certificate for the wrong domain due to improperly used crypto.

This could lead to remote information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.Product: Android Versions: Android-8.1 Android-9 Android-10 Android-11Android ID: A-171980069

Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty before version 4.1.59.Final there is a vulnerability on Unix-like systems involving an insecure temp file.

When netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. On unix-like systems, the temporary directory is shared between all user.

As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems.

The method "File.createTempFile" on unix-like systems creates a random file, but, by default will create this file with the permissions "-rw-r--r--". Thus, if sensitive information is written to this file, other local users can read this information. This is the case in netty's "AbstractDiskHttpData" is vulnerable. This has been fixed in version 4.1.59.Final.

As a workaround, one may specify your own "java.io.tmpdir" when you start the JVM or use "DefaultHttpDataFactory.setBaseDir(...)" to set the directory to something that is only readable by the current user.

Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling.

If a Content-Length header is present in the original HTTP/2 request, the field is not validated by 'Http2MultiplexHandler' as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1.

If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec` and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling.

In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory.

Users are only affected if all of this is true: 'HTTP2MultiplexCodec or Http2FrameCodec' is used, 'Http2StreamFrameToHttpObjectCodec' is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer.

This has been patched in 4.1.60.Final. As a workaround, the user can do the validation by themselves by implementing a custom 'ChannelInboundHandler' that is put in the 'ChannelPipeline' behind `Http2StreamFrameToHttpObjectCodec`.

Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.61.Final there is a vulnerability that enables request smuggling.

The content-length header is not correctly validated if the request only uses a single Http2HeaderFrame with the endStream set to true. This could lead to request smuggling if the request is proxied to a remote peer and translated to HTTP/1.1. This is a followup of GHSA-wm47-8v5p-wjpj/CVE-2021-21295 which did miss to fix this one case. This was fixed as part of 4.1.61.Final.

Neo4j through 3.4.18 (with the shell server enabled) exposes an RMI service that arbitrarily deserializes Java objects, e.g., through setSessionVariable.

An attacker can abuse this for remote code execution because there are dependencies with exploitable gadget chains.

The Bzip2 decompression decoder function doesn't allow setting size restrictions on the decompressed output data (which affects the allocation size used during decompression).

All users of Bzip2Decoder are affected. The malicious input can trigger an OOME and so a DoS attack.

The Snappy frame decoder function doesn't restrict the chunk length which may lead to excessive memory usage.

Beside this it also may buffer reserved skippable chunks until the whole chunk was received which may lead to excessive memory usage as well.

This vulnerability can be triggered by supplying malicious input that decompresses to a very big size (via a network stream or a file) or by sending a huge skippable chunk.

Prior to Apache Commons Net 3.9.0, Net's FTP client trusts the host from PASV response by default.

A malicious server can redirect the Commons Net code to use a different host, but the user has to connect to the malicious server in the first place.

This may lead to leakage of information about services running on the private network of the client. The default in version 3.9.0 is now false to ignore such hosts, as cURL does. See https://issues.apache.org/jira/browse/NET-711.

Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Netty prior to version 4.1.71.Final skips control chars when they are present at the beginning / end of the header name.

It should instead fail fast as these are not allowed by the spec and could lead to HTTP request smuggling.

Failing to do the validation might cause netty to "sanitize" header names before it forward these to another remote system when used as proxy. This remote system can't see the invalid usage anymore, and therefore does not do the validation itself.

Users should upgrade to version 4.1.71.Final.

SnakeYaml's Constructor() class does not restrict types which can be instantiated during deserialization.

Deserializing yaml content provided by an attacker can lead to remote code execution.

We recommend using SnakeYaml's SafeConsturctor when parsing untrusted content to restrict deserialization. We recommend upgrading to version 2.0 and beyond.

Netty is an open-source, asynchronous event-driven network application framework. The package io.netty:netty-codec-http prior to version 4.1.77.Final contains an insufficient fix for CVE-2021-21290.

When Netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled.

This only impacts applications running on Java version 6 and lower. Additionally, this vulnerability impacts code running on Unix-like systems, and very old versions of Mac OSX and Windows as they all share the system temporary directory between all users.

Version 4.1.77.Final contains a patch for this vulnerability. As a workaround, specify one's own java.io.tmpdir when starting the JVM or use DefaultHttpDataFactory.setBaseDir(...) to set the directory to something that is only readable by the current user.

The package org.yaml:snakeyaml from 0 and before 1.31 are vulnerable to Denial of Service (DoS) due missing to nested depth limitation for collections.

Azure Storage Library Information Disclosure Vulnerability

Using snakeYAML to parse untrusted YAML files may be vulnerable to Denial of Service attacks (DOS).

If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow.

Using snakeYAML to parse untrusted YAML files may be vulnerable to Denial of Service attacks (DOS).

If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow.

Using snakeYAML to parse untrusted YAML files may be vulnerable to Denial of Service attacks (DOS).

If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow.

Using snakeYAML to parse untrusted YAML files may be vulnerable to Denial of Service attacks (DOS).

If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stack-overflow.

Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS).

If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow. This effect may support a denial of service attack.

Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS).

If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by Out of memory. This effect may support a denial of service attack.

Those using Woodstox to parse XML data may be vulnerable to Denial of Service attacks (DOS) if DTD support is enabled.

If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow. This effect may support a denial of service attack.

Those using Snakeyaml to parse untrusted YAML files may be vulnerable to Denial of Service attacks (DOS).

If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stack overflow. This effect may support a denial of service attack.

Netty project is an event-driven asynchronous network application framework. In versions prior to 4.1.86.Final, a StackOverflowError can be raised when parsing a malformed crafted message due to an infinite recursion.

This issue is patched in version 4.1.86.Final. There is no workaround, except using a custom HaProxyMessageDecoder.

A stack overflow in Jettison before v1.5.2 allows attackers to cause a Denial of Service (DoS) via crafted JSON data.

Jettison before v1.5.2 was discovered to contain a stack overflow via the map parameter. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted string.

A flaw was found in Red Hat's AMQ-Streams, which ships a version of the OKHttp component with an information disclosure flaw via an exception triggered by a header containing an illegal value.

This issue could allow an authenticated attacker to access information outside of their regular permissions.

An infinite recursion is triggered in Jettison when constructing a JSONArray from a Collection that contains a self-reference in one of its elements.

This leads to a StackOverflowError exception being thrown.

Spring Framework running version 6.0.0 - 6.0.6 or 5.3.0-5.3.25 using as a pattern in Spring Security configuration with the mvcRequestMatcher creates a mismatch in pattern matching between Spring Security and Spring MVC, and the potential for a security bypass.

In Spring Framework versions 6.0.0 - 6.0.6, 5.3.0-5.3.25, 5.2.0.RELEASE - 5.2.22.RELEASE, and older unsupported versions, it is possible for a user to provide a specially crafted SpEL expression that may cause a denial-of-service (DoS) condition.

In spring framework versions prior to 5.2.24 release+, 5.3.27+ and 6.0.8+, it is possible for a user to provide a specially crafted SpEL expression that may cause a denial-of-service (DoS) condition.

The `spring-security.xsd` file inside the `spring-security-config` jar is world writable which means that if it were extracted it could be written by anyone with access to the file system.

While there are no known exploits, this is an example of "CWE-732: Incorrect Permission Assignment for Critical Resource" and could result in an exploit.

Users should update to the latest version of Spring Security to mitigate any future exploits found around this issue.

snappy-java is a fast compressor/decompressor for Java. Due to unchecked multiplications, an integer overflow may occur in versions prior to 1.1.10.1, causing a fatal erroг.

The function `shuffle(int[] input)` in the file `BitShuffle.java` receives an array of integers and applies a bit shuffle on it. It does so by multiplying the length by 4 and passing it to the natively compiled shuffle function.

Since the length is not tested, the multiplication by four can cause an integer overflow and become a smaller value than the true size, or even zero or negative.

In the case of a negative value, a `java.lang.NegativeArraySizeException` exception will raise, which can crash the program. In a case of a value that is zero or too small, the code that afterwards references the shuffled array will assume a bigger size of the array, which might cause exceptions such as `java.lang.ArrayIndexOutOfBoundsException`.

The same issue exists also when using the `shuffle` functions that receive a double, float, long and short, each using a different multiplier that may cause the same issue.

Version 1.1.10.1 contains a patch for this vulnerability.

snappy-java is a fast compressor/decompressor for Java. Due to unchecked multiplications, an integer overflow may occur in versions prior to 1.1.10.1, causing an unrecoverable fatal error.

The function `compress(char[] input)` in the file `Snappy.java` receives an array of characters and compresses it. It does so by multiplying the length by 2 and passing it to the rawCompress function.

Since the length is not tested, the multiplication by two can cause an integer overflow and become negative.

The rawCompress function then uses the received length and passes it to the natively compiled maxCompressedLength function, using the returned value to allocate a byte array.

Since the maxCompressedLength function treats the length as an unsigned integer, it doesn't care that it is negative, and it returns a valid value, which is casted to a signed integer by the Java engine.

If the result is negative, a `java.lang.NegativeArraySizeException` exception will be raised while trying to allocate the array `buf`. On the other side, if the result is positive, the `buf` array will successfully be allocated, but its size might be too small to use for the compression, causing a fatal Access Violation error.

The same issue exists also when using the `compress` functions that receive double, float, int, long and short, each using a different multiplier that may cause the same issue. The issue most likely won't occur when using a byte array, since creating a byte array of size $0\times80000000$ (or any other negative value) is impossible in the first place.

Version 1.1.10.1 contains a patch for this issue.

snappy-java is a fast compressor/decompressor for Java. Due to use of an unchecked chunk length, an unrecoverable fatal error can occur in versions prior to 1.1.10.1.

The code in the function `hasNextChunk` in the file `SnappyInputStream.java` checks if a given stream has more chunks to read. It does that by attempting to read 4 bytes. If it wasn't possible to read the 4 bytes, the function returns false. Otherwise, if 4 bytes were available, the code treats them as the length of the next chunk.

In the case that the `compressed` variable is null, a byte array is allocated with the size given by the input data.

Since the code doesn't test the legality of the `chunkSize` variable, it is possible to pass a negative number (such as 0xFFFFFFFF which is -1), which will cause the code to raise a `java.lang.NegativeArraySizeException` exception. A worse case would happen when passing a huge positive value (such as 0x7FFFFFFF), which would raise the fatal `java.lang.OutOfMemoryError` error.

Version 1.1.10.1 contains a patch for this issue.

Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients.

The SniHandler can allocate up to 16MB of heap for each channel during the TLS handshake.

When the handler or the channel does not have an idle timeout, it can be used to make a TCP server using the `SniHandler` to allocate 16MB of heap.

The `SniHandler` class is a handler that waits for the TLS handshake to configure a `SslHandler` according to the indicated server name by the ClientHello record. For this matter it allocates a `ByteBuf` using the value defined in the ClientHello record.

Normally the value of the packet should be smaller than the handshake packet but there are not checks done here and the way the code is written, it is possible to craft a packet that makes the SslClientHelloHandler.

This vulnerability has been fixed in version 4.1.94.Final.

Azure Identity SDK Remote Code Execution Vulnerability

When deserializing untrusted or corrupted data, it is possible for a reader to consume memory beyond the allowed constraints and thus lead to out of memory on the system.

This issue affects Java applications using Apache Avro Java SDK up to and including 1.11.2.

Users should update to apache-avro version 1.11.3 which addresses this issue.

snappy-java is a Java port of the snappy, a fast C++ compresser/decompresser developed by Google.

The SnappyInputStream was found to be vulnerable to Denial of Service (DoS) attacks when decompressing data with a too large chunk size.

Due to missing upper bound check on chunk length, an unrecoverable fatal error can occur.

All versions of snappy-java including the latest released version 1.1.10.3 are vulnerable to this issue.

A fix has been introduced in commit 9f8c3cf74 which will be included in the 1.1.10.4 release. Users are advised to upgrade. Users unable to upgrade should only accept compressed data from trusted sources.

The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023.

In Connect2id Nimbus JOSE+JWT before 9.37.2, an attacker can cause a denial of service (resource consumption) via a large JWE p2c header value (aka iteration count) for the PasswordBased Decrypter (PBKDF2) component.

In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body.

This can result in corrupted and/or inadvertent sharing of data between requests.

In Spring Security, versions 5.7.x prior to 5.7.12, 5.8.x prior to 5.8.11, versions 6.0.x prior to 6.0.9, versions 6.1.x prior to 6.1.8, versions 6.2.x prior to 6.2.3, an application is possible vulnerable to broken access control when it directly uses the `AuthenticatedVoter#vote` passing a null Authentication parameter.

Out-of-bounds Write vulnerability in Apache Commons Configuration. This issue affects Apache Commons Configuration: from 2.0 before 2.10.1.

Users are recommended to upgrade to version 2.10.1, which fixes the issue.

Out-of-bounds Write vulnerability in Apache Commons Configuration. This issue affects Apache Commons Configuration: from 2.0 before 2.10.1.

Users are recommended to upgrade to version 2.10.1, which fixes the issue.

Azure Identity Libraries and Microsoft Authentication Library Elevation of Privilege Vulnerability

The fix for CVE-2022-22968 made disallowed Fields patterns in DataBinder case insensitive.

However, String.toLowerCase() has some Locale dependent exceptions that could potentially result in fields not protected as expected.

Azure Command Line Integration (CLI) Elevation of Privilege Vulnerability

Schema parsing in the Java SDK of Apache Avro 1.11.3 and previous versions allows bad actors to execute arbitrary code.

Users are recommended to upgrade to version 1.11.4 or 1.12.0, which fix this issue.

Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine. It includes a utility class, HttpURI, for URI/URL parsing.

The HttpURI class does insufficient validation on the authority segment of a URI. However the behaviour of HttpURI differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC.

Specifically HttpURI and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks.

There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack.

By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory.

`BCryptPasswordEncoder.matches(CharSequence, String)` will incorrectly return true for passwords larger than 72 characters as long as the first 72 characters are the same.

Netty, an asynchronous, event-driven network application framework, has a vulnerability in versions up to and including 4.1.118.Final. An unsafe reading of environment file could potentially cause a denial of service in Netty. When loaded on an Windows application, Netty attempts to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. A similar issue was previously reported as CVE-2024-47535.

This issue was fixed, but the fix was incomplete in that null-bytes were not counted against the input limit. Commit d1fbda62d3a47835d3fb35db8bd42ecc205a5386 contains an updated fix.

Relative Path Traversal vulnerability in Apache Commons VFS before 2.10.0.

The FileObject API in Commons VFS has a 'resolveFile' method that takes a 'scope' parameter.

Specifying `NameScope.DESCENDENT` promises that "an exception is thrown if the resolved file is not a descendent of the base file".

However, when the path contains encoded ".." characters (for example, "%2E%2E/bar.txt"), it might return file objects that are not a descendent of the base file, without throwing an exception.

This issue affects Apache Commons VFS: before 2.10.0. Users are recommended to upgrade to version 2.10.0, which fixes the issue.

Spring Security Aspects may not correctly locate method security annotations on private methods. This can cause an authorization bypass.

Your application may be affected by this if the following are true: You are using `@EnableMethodSecurity(mode=ASPECTJ)` and `spring-security-aspects`, and you have Spring Security method annotations on a private method.

In that case, the target method may be able to be invoked without proper authorization.

You are not affected if: You are not using `@EnableMethodSecurity(mode=ASPECTJ)` or `spring-security-aspects`, or You have no Spring Security-annotated private methods.

In Spring Framework, versions 6.0.x as of 6.0.5, versions 6.1.x and 6.2.x, an application is vulnerable to a reflected file download (RFD) attack when it sets a "Content-Disposition" header with a non-ASCII charset, where the filename attribute is derived from user-supplied input.

Specifically, an application is vulnerable when all the following are true: The header is prepared with `org.springframework.http.ContentDisposition`.

The filename is set via `ContentDisposition.Builder#filename(String, Charset)`. The value for the filename is derived from user-supplied input. The application does not sanitize the user-supplied input. The downloaded content of the response is injected with malicious commands by the attacker (see RFD paper reference for details).

An application is not vulnerable if any of the following is true: The application does not set a "Content-Disposition" response header. The header is not prepared with `org.springframework.http.ContentDisposition`. The filename is set via one of: `ContentDisposition.Builder#filename(String)`, or `ContentDisposition.Builder#filename(String, ASCII)`. The filename is not derived from user-supplied input. The filename is derived from user-supplied input but sanitized by the application. The attacker cannot inject malicious content in the downloaded content of the response.

Affected Spring Products and VersionsSpring Framework: 6.2.0-6.2.7, 6.1.0-6.1.20, 6.0.5-6.0.28. Older, unsupported versions are not affected.

Mitigation: Users of affected versions should upgrade to the corresponding fixed version.

Affected version(s) Fix versionAvailability: 6.2.x to 6.2.8 OSS, 6.1.x to 6.1.21 OSS, 6.0.x to 6.0.29 Commercial https://enterprise.spring.io/ No further mitigation steps are necessary.

CWE-113 in `Content-Disposition` handling in VMware Spring Framework versions 6.0.5 to 6.2.7 allows remote attackers to launch Reflected File Download (RFD) attacks via unsanitized user input in 'ContentDisposition.Builder#filename(String, Charset) with non-ASCII charsets.

Uncontrolled Recursion vulnerability in Apache Commons Lang.

This issue affects Apache Commons Lang: Starting with `commons-lang:commons-lang` 2.0 to 2.6, and, from `org.apache.commons:commons-lang3` 3.0 before 3.18.0.

The methods `ClassUtils.getClass(...)` can throw `StackOverflowError` on very long inputs.

Because an Error is usually not handled by applications and libraries, a `StackOverflowError` could cause an application to stop.

Users are recommended to upgrade to version 3.18.0, which fixes the issue.

Allocation of resources for multipart headers with insufficient limits enabled a DoS vulnerability in Apache Commons FileUpload.

This issue affects Apache Commons FileUpload: from 1.0 before 1.6; from 2.0.0-M1 before 2.0.0-M4.

Users are recommended to upgrade to versions 1.6 or 2.0.0-M4, which fix the issue.