-
Notifications
You must be signed in to change notification settings - Fork 428
Security Vulnerability due to System.Text.RegularExpressions #1786
Comments
A .Net Standard library is not used on its own, it's used as a part of some application. And an application will generally use an implementation of .Net Standard that comes from the framework it uses. So it shouldn't matter if the library depends on an insecure version of System.Text.RegularExpressions, because the application will actually use a secure version of System.Text.RegularExpressions (assuming it's running on an up-to-date version of .Net Framework, .Net Core or .Net). Because of that, I think the report of a vulnerability that's affecting your code is effectively a false positive. (Note that I don't work for Microsoft and that I don't speak in any official capacity. If you still believe that a security vulnerability exists here, I think you should follow the .Net Core security policy to report it directly to Microsoft's security team, especially considering it's now a vacation season.) |
As mentioned earlier microsoft has already fixed in core as per below commit: dotnet/corefx@19d4b11. While you are right that if an up-to-date version of .net framework/core is installed, the host application would load the latest secure version, but this would not be the case if servers not up-to-date or as pointed out by microsoft in the case of pinned applications to a specific version. Thats because i think, the minimum dependency version of System.Text.RegularExpressions specified by net standard is still pointing to the insecured version of 4.3.0 as per the dependency file. By incrementing it to 4.3.1, we could eliminate the possibility of using the older insecured version. |
System.Text.RegularExpressions never applies a vulnerable binary on .NETFramework. It applies a facade dll that typeforwards to System.dll where all this code lives. The facade dll is not vulnerable as it does not contain the code. System.Text.RegularExpressions also does not apply its binary on .NETCore2.0 and later. There the implementation is provided by the shared framework. This package only exists for delivering the implementation to older frameworks (.netcore1.x), which are now out of support. In general we don't churn the entire package ecosystem when a single package is updated. If you'd like to update your package reference to suppress this false positive from a validation tool you may. This wouldn't be much different than if we shipped a new version of NETStandard.Library, you'd still need all the packages that referenced the old version to update to a new one. |
System.Text.RegularExpressions v4.3.1 is also flagged as well! It is the latest version available that I could see. |
Problem
There is a security vulnerability with the version of System.Text.RegularExpressions that is used by dotnet standard. The vulnerable version of System.Text.RegularExpressions is 4.3.0. Please see links below for the vulnerability documentation or discussion:
https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2019-0820
dotnet/announcements#111
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0820
https://snyk.io/vuln/SNYK-DOTNET-SYSTEMTEXTREGULAREXPRESSIONS-174708
https://www.whitesourcesoftware.com/vulnerability-database/CVE-2019-0820
The dotnet commit that fixed the vulnerability is dotnet/corefx@19d4b11
Issue:
We use whitesource and it has caught this issue with high severity. We don't consume System.Text.RegularExpressions directly but packages that use this. Therefore as a transitive dependency due to NetStandard library, which is being used by several other dotnet packages like Castle Windsor, MassTransit etc., Once an update is available the others could followup and update.
Code:
The latest version 2.0.3 of Net standard still seem to be using System.Text.RegularExpressions version 4.3.0 as per https://github.com/dotnet/standard/blob/master/src/apicompat/netstandard/netstandard.depproj
Fix
Please update library targeting .netStandard 1.6 to update System.Text.RegularExpression package to latest secured version 4.3.1 to fix the security issue or kindly suggest alternatives.
The text was updated successfully, but these errors were encountered: