Page Comparison

...

There are three main challenges that should be taken into consideration in order to understand WhiteSource’s support for GO projects:

• Commits are pushed to GO repositories at a high rate (several times per day).

• GO repositories are relatively large in size.

• GO provides an option to use the “latest” package, meaning the latest commit pushed to the repository.

The combination of these three factors create difficulty when scanning GO projects, and retrieving the exact commit that was used would cause WhiteSource scans for GO projects to take an exceptionally long time.

...

• 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

...

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 WhiteSource 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 WhiteSource.

• 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.

WhiteSource contacted Microsoft officials regarding the above, and Microsoft officials verified that WhiteSource’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.

...