Overview

This page provides WhiteSource notices for its customers.

To ensure that you remain updated, WhiteSource recommends that you subscribe to the Customer Community Portal Announcements section in order to receive immediate email notifications on important announcements, and follow the biweekly release notes. 

Name Changes

File System Agent

The WhiteSource File System Agent (FSA) has been renamed to the WhiteSource Unified Agent. 

Sun License

The name of the Sun license was changed to Sun Public License. (21.3.2, 4/11/21)

New and/or Modified Documentation

Unified Agent Parameter Merging (version 21.4.2)

Beginning in this version, nuget.runPreStep and nuget.restoreDependencies will be combined. This works the following way: if nuget.runPreStep = true, then dotnet restore will be performed on found .csproj files. As a result of this merge, nuget.restoreDependencies will be deprecated.

New Unified Agent Documentation (version 20.10.2)

Beginning in version 20.10.2, a modified and updated Unified Agent documentation repository has been launched, with the intent to increase usability, update existing content, fill in missing gaps, and create a linear flow.

The documentation is now spread over 4 contiguous topics (pages), in this order:

New Policies Documentation (version 20.10.2)

Beginning in version 20.10.2 (approximate release - November 8), a modified Policies page has been launched, with the intent to update existing content, fill in missing gaps, and create a linear flow.

This page merges the two existing policies topics - Automated Policies and Managing Policies Throughout Your SDLC. The latter has been archived and therefore no longer in use.

Notices of Deprecation

Documentation

Version 21.5.2

The following pages were deprecated:

Version 21.4.2

Beginning in this version the following pages were archived and are therefore no longer in use:

Version 21.3.2

Beginning in this version the following pages were archived and are therefore no longer in use:

Version 21.2.2

Beginning in this version the following page was archived and is therefore no longer in use.

Version 21.2.1

Beginning in this version the following page was archived and is therefore no longer in use.

Version 21.1.2

Beginning in this version the following integration pages were archived and are therefore no longer in use. The material contained therein is contained in the Unified Agent parameter documentation.

The following topics have been completely deprecated and are therefore no longer in use:

Version 20.12.2

Beginning in version 20.12.2 the following integration pages were archived and are therefore no longer in use. The material contained therein is contained in the Unified Agent parameter documentation.

Version 20.12.1

Beginning in version 20.12.1 the following integration pages will be archived and therefore no longer be in use. The material contained therein is contained in the Unified Agent parameter documentation.

Additionally, the following pages will be archived:

Features

TeamCity Plugin End-of-Life

The TeamCity plugin will reach its End Of Life starting November 1, 2021. After this date, WhiteSource will no longer provide standard support, including updates and fixes, for the deprecated plugin. Extended Support, which is limited to configuration and Support troubleshooting, will continue until May 1, 2022. Following this date, the TeamCity plugin will no longer be supported by WhiteSource. Please make sure to migrate to the Unified Agent before the end of standard support on November 1, 2021 to maintain full support o

API Version 1.0 and Below

Beginning on February 15, 2020, WhiteSource will deprecate API version 1.0 and below for new developments to make way for the more advanced and secure versions 1.1, 1.2 and 1.3. Support for 1.0 versions and below will end six months from that date (August 15, 2020).

Additionally, on February 15, 2020, WhiteSource will begin enforcing the quota limits for API usage per customer according to the contract. Please prepare accordingly for these changes. For any questions or concerns, contact WhiteSource support. 

IntelliJ Old Plugin End of Life

On July 12, 2020, WhiteSource will deprecate the old plugin version of WhiteSource Advise for IntelliJ (see here).

A new WhiteSource Advise plugin is already available directly from the IntelliJ IDEA Marketplace (see here), which besides offering the same features as the old plugin, includes functionality improvements as well as performance-related enhancements.

Please make sure to migrate to the new plugin by deleting the old plugin and then only installing the new one. See our documentation for more information.

NuGet Plugin End of Life

With the wide functionality of the WhiteSource Unified Agent providing support for more than 200 languages, the NuGet plugin will reach its End Of Life starting October 1, 2020.

After this date, WhiteSource will no longer provide standard support, including updates and fixes, for the deprecated plugin. Extended Support, which is limited to configuration and Support troubleshooting, will continue until April 1, 2021. Following this date, the NuGet plugin will no longer be supported by WhiteSource. Please make sure to migrate to the Unified Agent before the end of standard support on October 1, 2020 to maintain full support of your product.  

Jfrog Xray Integration Support

JFrog's vulnerability data integration strategy has changed: Integration with third-party providers of solutions that scan open-source libraries will no longer be available. Therefore, WhiteSource’s Xray Integration will be deprecated.

Shared customers integrating Xray with WhiteSource will no longer be supported or maintained by JFrog. Note that existing integrations with JFrog Artifactory (independent of JFrog Xray) are not affected.WhiteSource invites you to continue to use its variety of supported integrations for detecting vulnerabilities in open-source software. For more information, contact support@whitesourcesoftware.com.

NPM and Maven GitHub Repositories - Visibility Change

Following the deprecation of NPM and Maven Plugins, the visibility of existing GitHub repositories was changed to 'private'.

Deprecation of the Vulnerable Methods

In some cases, vulnerabilities are fixed by the deprecation of the vulnerable classes or methods. To that extent, WhiteSource, as other official advisories, will mark the vulnerabilities as fixed with the relevant version. In these cases, the vulnerabilities are fixed by adding "@Deprecated" to the vulnerable method.

Example:

Parameters

Scan Results

GO Scan Results

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

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.

In order to overcome the challenges described above, whenever the given SHA-1 isn’t immediately recognized by WhiteSource, an approximate result is provided while WhiteSource imports the exact requested commit. Whenever a library displayed in the WhiteSource UI as an approximated result, it will be displayed as such with a disclaimer in the library details page while the exact commit is imported in the background. Once the exact commit is imported, it will automatically replace the approximate result in your inventory.

Unified Agent

Notice for Customers Using the Direct Link to Download the Unified Agent .jar File

Note that beginning in release 19.7.1 only the new Unified Agent .jar download link will be operational.

Contact WhiteSource Support if further assistance is needed.

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

.NET Core and ASP.NET Core DLL Files

This notice regards the following CVEs:

CVE Reference

Issue Reference

Affected Environments

CVE-2017-0248

Microsoft Security Advisory 4021279: Vulnerabilities in .NET Core, ASP.NET Core Could Allow Elevation of Privilege #239

MSRC - CVE-2017-0248

CVE-2017-0247

Microsoft Security Advisory 4021279: Vulnerabilities in .NET Core, ASP.NET Core Could Allow Elevation of Privilege #239

CVE-2017-0256

Microsoft Security Advisory 4021279: Vulnerabilities in .NET Core, ASP.NET Core Could Allow Elevation of Privilege #239

CVE-2017-0249

Microsoft Security Advisory 4021279: Vulnerabilities in .NET Core, ASP.NET Core Could Allow Elevation of Privilege #239

CVE-2019-0820

Microsoft Security Advisory CVE-2019-0820: .NET Core Denial of Service Vulnerability #111

MSRC - CVE-2019-0820

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 WhiteSource 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 WhiteSource 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, WhiteSource 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, WhiteSource 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 WhiteSource 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), WhiteSource 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 WhiteSource 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

Vulnerable Projects

Project

Vulnerabilities

Vulnerable Versions

Mitigation

Apache Traffic Server

CVE-2019-9511, CVE-2019-9512, CVE-2019-9513, CVE-2019-9514, CVE-2019-9515, CVE-2019-9516, CVE-2019-9517, CVE-2019-9518.

6.x: 6.0 - 6.2.3
7.x: 7.0 - 7.1.6
8.x: 8.0 -  8.1.3

6.x: No fix available.
7.x: Upgrade to 7.1.7 (patch).
8.x: Upgrade to 8.1.4 (patch).

Go

CVE-2019-9512, CVE-2019-9514. Official Website Advisory

1.11.x: 1.11.0 - 1.11.12
1.12.x: 1.12.0 - 1.12.7

1.11.x: Upgrade to 1.11.13 (patch).
1.12.x: Upgrade to 1.12.8 (patch).

H2O

CVE-2019-9512, CVE-2019-9514, CVE-2019-9515. Official Website Advisory

2.2.x: 2.2.0 - 2.2.5
2.3.x: 2.3.0-beta1

2.2.x: Upgrade to 2.2.6 (patch).
2.3.x: Upgrade to 2.3.0-beta2 (patch).

Eclipse Jetty

CVE-2019-9511, CVE-2019-9512, CVE-2019-9513, CVE-2019-9514, CVE-2019-9515, CVE-2019-9516, CVE-2019-9517, CVE-2019-9518. Official Website Advisory

9.3.x - 9.4.20

Upgrade to 9.4.21 (patch).

Netty

CVE-2019-9512, CVE-2019-9514, CVE-2019-9515, CVE-2019-9518. Official Website Advisory

4.1.0-beta4 - 4.1.38

Upgrade to 4.1.39 (patch-1 [9512, 9514, 9515], patch-2 [9518]).

Nghttp2

CVE-2019-9511, CVE-2019-9513. Official Website Advisory

0.1.0 - 1.39.1

Upgrade to 1.39.2 (patch-1patch-2).

NGINX

CVE-2019-9511, CVE-2019-9513, CVE-2019-9516. Official Website Advisory

NOTE: The releases (X.Y.Z) splitted into two types: if Y is divisible by 2 - stable, otherwise - mainline.
Stable: 0.2.x - 1.16.0
Mainline:  0.1.x - 1.17.2

Stable: Upgrade to 1.16.1 (patch-1 [9511], patch-2 [9513], patch-3 [9516]).
Mainline: Upgrade to 1.17.3 (patch-1 [9511], patch-2 [9513], patch-3 [9516]).

NodeJS

CVE-2019-9511, CVE-2019-9512, CVE-2019-9513, CVE-2019-9514, CVE-2019-9515, CVE-2019-9516, CVE-2019-9517, CVE-2019-9518. Official Website Advisory

8.x: 8.0.0 - 8.16.0
10.x: 10.0.0 - 1.16.2
12.x: 12.0.0 - 12.8.0 

8.x: Upgrade to 8.16.1 (patch-1 [9511, 9517], patch-2 [9511, 9517], patch-3 [9512, 9515], patch-4 [9512, 9515], patch-5 [9513], patch-6 [9513], patch-7 [9514], patch-8 [9514], patch-9 [9516], patch-10 [9518]).
10.x: Upgrade to 10.16.3 (patch-1 [9511, 9517], patch-2 [9511, 9517], patch-3 [9512, 9515], patch-4 [9512, 9515], patch-5 [9513], patch-6 [9513], patch-7 [9514], patch-8 [9514], patch-9 [9516], patch-10 [9518]).
12.x: Upgrade to 12.8.1 (patch-1 [9511, 9517], patch-2 [9511, 9517], patch-3 [9512, 9515], patch-4 [9512, 9515], patch-5 [9513], patch-6 [9513], patch-7 [9514], patch-8 [9514], patch-9 [9516], patch-10 [9518]).

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

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.

References

Azure DevOps

Major improvements to the Azure DevOps integration will be introduced in July 2021. The underlying scanning mechanism will be modified to allow a direct WhiteSource scan from within the Azure DevOps pipeline. As part of this change, the following updates will be introduced: