Legacy SCA - Notices

Overview

This page provides Mend notices for its customers. It is also recommended to check the Release Notes that are updated biweekly.

Vulnerability Notices

Spring HTTP Invokers

Note to Customers: Spring has announced that vulnerability CVE-2016-1000027, found in version 4.1, will not be fixed for future versions. For more information, please see below. 

Spring HTTP invokers are both lightweight protocols that use their own slim serialization mechanisms and use the standard Java serialization mechanism to expose services through HTTP. This has a huge advantage if your arguments and return types are complex types that cannot be serialized by using the serialization mechanisms Hessian uses (see the next section for more considerations when you choose a remoting technology).

Under the hood, Spring uses either the standard facilities provided by the JDK or Apache HttpComponents to perform HTTP calls. If you need more advanced and easier-to-use functionality, use the latter. See hc.apache.org/httpcomponents-client-ga/ for more information.

Be aware of vulnerabilities due to unsafe Java deserialization: Manipulated input streams can lead to unwanted code execution on the server during the deserialization step. As a consequence, do not expose HTTP invoker endpoints to untrusted clients. Rather, expose them only between your own services. In general, we strongly recommend using any other message format (such as JSON) instead.

If you are concerned about security vulnerabilities due to Java serialization, consider the general-purpose serialization filter mechanism at the core JVM level, originally developed for JDK 9 but backported to JDK 8, 7 and 6 in the meantime. See https://blogs.oracle.com/java-platform-group/entry/incoming_filter_serialization_data_a and https://openjdk.java.net/jeps/290

Microsoft Packages and DLL Files

.NET Core and ASP.NET Core DLL Files

This notice regards the following CVEs:

The issues mentioned above refer to several names and versions of NuGet packages containing vulnerable DLL libraries, along with the NuGet package versions containing a fixed DLL library. However, according to their SHA-1 identifiers, some of the vulnerable DLL libraries still exist in other directories of the fixed NuGet packages. Therefore, the fixed version for each NuGet package refers to a package that isn'tunconditionally vulnerable, but ispotentially vulnerable depending on the specifications of the run-time environment.

Taking into consideration the fact that the vulnerable DLL libraries may still be loaded and that Mend retrieves the SHA-1 identifiers of the DLL libraries after the NuGet package is built, the vulnerabilities mentioned above will continue to be reported by Mend so users can ensure their environment isn't vulnerable.

Example: 

According to Microsoft, the vulnerability found in CVE-2017-0247, referring to the vulnerable DLL library with the SHA-1 identifier below, was present in versions 4.0.1 and 4.3.0, and fixed in versions 4.0.2 and 4.3.1 of the 'System.Net.Http.WinHttpHandler' NuGet package. However, you can see below that version 4.4.0 of the 'System.Net.Http.WinHttpHandler' NuGet package still contains the vulnerable DLL files. 

Version 4.3.0 of System.Net.Http.WinHttpHandler NuGet package: 

Version 4.4.0 of 'System.Net.Http.WinHttpHandler' NuGet package:

CVE and WS Vulnerability Identifiers

As many of you know, OSS vulnerabilities are published in multiple advisories.The National Vulnerability Database (NVD) is commonly acknowledged as a primary database for known security vulnerabilities but has been arguably slow in adopting data from advisories. In order to attain broader coverage of reported security vulnerabilities, Mend has not been relying solely on the NVD but has been reviewing vulnerability data from dozens of additional sources as well. Whereas the NVD publishes security vulnerabilities using a "CVE-" prefixed identifier, Mend classifies non-NVD security vulnerabilities using a "WS-" prefix.Recently, we have noticed that the NVD features support for additional sources, potentially enabling it to encompass security vulnerabilities that are already flagged by Mend using a designated "WS-" identifier.

What is being changed?

To avoid duplicate, redundant identifiers for vulnerabilities (i.e., "WS-" and "CVE-" entries that refer to the same vulnerability), Mend will replace non-NVD, "WS-" entries with the corresponding NVD, "CVE-" entries featuring associated CVE metadata, thereby enabling customers to benefit from the extended coverage of pertinent vulnerabilities directly from the NVD. The new CVEs were assigned by NVD with a “CVE-2018-” prefix.

Are my reports or alerts affected?

(npm packages only) Customers may notice that some or all of the "WS-" entries previously featured in Mend displays and reports are no longer listed in their inventory. Such "WS-" entries are now listed with corresponding "CVE-" identifiers and feature the vulnerability metadata from the NVD.For these vulnerabilities, the severity and score may change.New alerts associated with vulnerabilities that were previously marked using a "WS-" identifier will be triggered as well with "CVE-" information.

HTTP/2 Denial of Service Vulnerabilities

Overview

HTTP/2 is a major revision of the HTTP network protocol used by the World Wide Web. The HTTP/2 specification was published as RFC 7540 in May 2015. HTTP/2 makes our applications faster, simpler, and more robust by allowing us to undo many of the HTTP/1.1 workarounds previously done within our applications and address these concerns within the transport layer itself. Even better, it also opens up a number of entirely new opportunities to optimize our applications and improve performance!

The primary goals for HTTP/2 are to reduce latency by enabling full request and response multiplexing, minimize protocol overhead via efficient compression of HTTP header fields, and add support for request prioritization and server push. To implement these requirements, there is a large supporting cast of other protocol enhancements, such as new flow control, error handling, and upgrade mechanisms, but these are the most important features that every web developer should understand and leverage in their applications.

HTTP/2 does not modify the application semantics of HTTP in any way. All the core concepts, such as HTTP methods, status codes, URIs, and header fields, remain in place. Instead, HTTP/2 modifies how the data is formatted (framed) and transported between the client and server, both of which manage the entire process, and hides all the complexity from our applications within the new framing layer. As a result, all existing applications can be delivered without modification.

Denial of Service Vulnerabilities Discovery

Netflix has discovered several resource exhaustion vectors affecting a variety of third-party HTTP/2 implementations. These attack vectors can be used to launch DoS attacks against servers that support HTTP/2 communication. Netflix worked with Google and CERT/CC to coordinate disclosure to the Internet community. A number of vendors have announced patches to correct this suboptimal behavior.

Impact

There are three broad areas of information security: confidentiality (information can’t be read by unauthorized people), integrity (information can’t be changed by unauthorized people), and availability (information and systems are available when you want them). All of the changes announced today are in the “availability” category. These HTTP/2 vulnerabilities do not allow an attacker to leak or modify information.

Rather, they allow a small number of low bandwidth malicious sessions to prevent connection participants from doing additional work. These attacks are likely to exhaust resources such that other connections or processes on the same machine may also be impacted or crash.

Vulnerabilities

• CVE-2019-9511 “Data Dribble”: The attacker requests a large amount of data from a specified resource over multiple streams. They manipulate window size and stream priority to force the server to queue the data in 1-byte chunks. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both, potentially leading to a denial of service.
  CVSS 3.x Score: 7.5 HIGH

• CVE-2019-9512 “Ping Flood”: The attacker sends continual pings to an HTTP/2 peer, causing the peer to build an internal queue of responses. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both, potentially leading to a denial of service.
  CVSS 3.x Score: 7.5 HIGH

• CVE-2019-9513 “Resource Loop”: The attacker creates multiple request streams and continually shuffles the priority of the streams in a way that causes substantial churn to the priority tree. This can consume excess CPU, potentially leading to a denial of service.
  CVSS 3.x Score: 7.5 HIGH

• CVE-2019-9514 “Reset Flood”: The attacker opens a number of streams and sends an invalid request over each stream that should solicit a stream of RST_STREAM frames from the peer. Depending on how the peer queues the RST_STREAM frames, this can consume excess memory, CPU, or both, potentially leading to a denial of service.
  CVSS 3.x Score: 7.5 HIGH

• CVE-2019-9515 “Settings Flood”: The attacker sends a stream of SETTINGS frames to the peer. Since the RFC requires that the peer reply with one acknowledgement per SETTINGS frame, an empty SETTINGS frame is almost equivalent in behavior to a ping. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both, potentially leading to a denial of service.
  CVSS 3.x Score: 7.5 HIGH

• CVE-2019-9516 “0-Length Headers Leak”: The attacker sends a stream of headers with a 0-length header name and 0-length header value, optionally Huffman encoded into 1-byte or greater headers. Some implementations allocate memory for these headers and keep the allocation alive until the session dies. This can consume excess memory, potentially leading to a denial of service.
  CVSS 3.x Score: 7.5 HIGH

• CVE-2019-9517 “Internal Data Buffering”: The attacker opens the HTTP/2 window so the peer can send without constraint; however, they leave the TCP window closed so the peer cannot actually write (many of) the bytes on the wire. The attacker then sends a stream of requests for a large response object. Depending on how the servers queue the responses, this can consume excess memory, CPU, or both, potentially leading to a denial of service.
  CVSS 3.x Score: 7.5 HIGH

• CVE-2019-9518 “Empty Frames Flood”: The attacker sends a stream of frames with an empty payload and without the end-of-stream flag. These frames can be DATA, HEADERS, CONTINUATION and/or PUSH_PROMISE. The peer spends time processing each frame disproportionate to attack bandwidth. This can consume excess CPU, potentially leading to a denial of service.
  CVSS 3.x Score: 7.5 HIGH

Vulnerable Projects

.Net Packages with no Vulnerable Code

Occasionally, NuGet packages that do not contain vulnerable elements are marked as vulnerable by multiple Microsoft advisories. This occurs for one of two reasons:

• The package is a metapackage. A metapackage is a package that does not contain any code, but only references other packages. Due to the fact that the package does not contain any code, the package itself cannot contain any vulnerable elements and Mend will not display any vulnerable elements.

  For example, according to this Microsoft Advisory, Microsoft.NETCore.App is vulnerable to CVE-2020-0603. However, this is only the case because Microsoft.NETCore.App references Microsoft.AspNetCore.All and Microsoft.AspNetCore.App which are the actual vulnerable packages. Microsoft.NETCore.App itself does not include any actual vulnerable code, and therefore will not be marked as vulnerable by mend.

• The package is only vulnerable if you are using a specific runtime dependency.

  For example, according to this Microsoft advisory, Microsoft.AspNetCore.Mvc is vulnerable. However, when comparing the vulnerable and fixed versions of Microsoft.AspNetCore.Mvc, you can see that they contain the same exact code implementation, meaning no vulnerable code exists in the Dlls within this package, but rather in the runtime dependencies it utilizes.

Mend contacted Microsoft officials regarding the above, and Microsoft officials verified that mend’s analysis is correct. Microsoft treats the cases mentioned above as vulnerable in order to raise awareness. Microsoft encourages updating the metapackage to ensure all vulnerable dependencies are updated, rather than updating only specific packages. The same approach is encouraged for runtime dependencies, where Microsoft encourages updating the entire runtime crucial environment packages, rather than referring to specific packages.

References

• https://docs.microsoft.com/en-us/aspnet/core/fundamentals/metapackage-app?view=aspnetcore-3.1

• https://docs.microsoft.com/en-us/aspnet/core/fundamentals/metapackage?view=aspnetcore-3.1

• https://github.com/dotnet/core/blob/master/release-notes/1.0/sdk/1.0-rc3-implicit-package-refs.md