-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Microsoft Security Advisory CVE-2019-0545: .NET Core Information Disclosure Vulnerability #28343
Comments
@blowdart When I check https://www.nuget.org/packages/System.Net.Http/ the latest version of the package is |
@leecow any idea what's going on here? |
@blowdart , @Tasteful - I've learned something new about this. Beginning with .NET Core 2.1, we do not ship "loose" packages for anything include in Microsoft.NETCore.App. For this announcement, that impacts our listings for System.Net.Http (and ZipFile in cve-2018-08416). To update affected 2.1 and 2.2 applications, pick up the new Microsoft.NETCore.App. |
When looking at our usages of Microsoft.NETCore.App I can only see SDK references: My understanding is that Microsoft.NETCore.App is a metapackage which in turn use the packages distributed with the .NET Core runtime. We're not using the metapackage directly (aside from the implicit SDK reference) and instead are still using explicit package references for .NET Core / ASP.NET Core dependencies as was tradition back in 1.x, however that means our System.Net.Http reference is still 4.3.4 and as @Tasteful has mentioned previously there's no updated build available. How do we protect ourselves from the MSA in this instance - await a 4.3.5 of System.Net.Http or is the intention that we remove explicit packages and reference the latest Microsoft.NETCore.App instead? |
This issue only affects SocketsHttpHandler (introduced since .NET Core 2.1), which doesn't exist in
If you are using SocketsHttpHandler (for .NET Core 2.1 and above this is the default handler), see Lee's comment: "To update affected 2.1 and 2.2 applications, pick up the new Microsoft.NETCore.App." |
Why does the 4.3.4 variant differ to the one included within Microsoft.NetCore.App - is it the same assembly albeit with a different version?
Our applications do not directly reference that type but instead use 4.3.4 of the System.Net.Http package. Additionally, our applications specify netcoreapp2.1 via their .csproj content:
I'm struggling to understand whether this means we are susceptible, as we are running against .NET Core 2.1 based on the configuration above yet we're not directly referencing the SocketsHttpHandler / Microsoft.NETCore.App package aside from the SDK installation. For reference we use |
We do not ship code in NuGet packages, unless we have to. System.Net.Http is mainly legacy for .NET Framework where we attempted to deliver value of innovation also to .NET Framework developers as opt-in and caused major problems which we reverted later - see details in #18280 and post-mortem in #20777.
You are not vulnerable. If you're running on .NET Core 2.1, the "inbox" code is used. The NuGet package is no-opt, it just "forwards" to the "inbox" version of the code, which is patched. I hope it helps. |
I have a .NET Framework application using System.Net.Http 4.3.2 nuget. Does this issue apply? |
Microsoft Security Advisory CVE-2019-0545: .NET Core Information Disclosure Vulnerability
Executive summary
Microsoft is releasing this security advisory to provide information about a vulnerability in .NET Core 2.1 and 2.2. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.
Microsoft is aware of an information disclosure vulnerability exists in .NET Framework and .NET Core which allows bypassing Cross-origin Resource Sharing (CORS) configurations. An attacker who successfully exploited the vulnerability could retrieve content, that is normally restricted, from a web application.
The security update addresses the vulnerability by enforcing CORS configuration to prevent its bypass.
Announcement
The original announcement for this issue can be found at dotnet/announcements#94
Mitigation factors
Microsoft has not identified any mitigating factors for this vulnerability.
Affected software
Any .NET Core based application that uses the System.Net.Http package with a vulnerable version listed below.
Advisory FAQ
How do I know if I am affected?
Applications that use Microsoft.NetCore.App
System.Net.Http
is distributed as part of the .NET Core 2.1 runtime. To check the currently installed runtimes, open a command prompt and run thedotnet --info
command. If you have a 2.1 or greater runtime installed, you'll see output like the following;If your host version is 2.1.x and the highest
Microsoft.NETCore.App
runtime version is less than 2.1.7, you're vulnerable to this issue.If your host version is 2.2.x and the highest 2.1.x
Microsoft.NETCore.App
runtime version is less than 2.1.7, you're vulnerable to this issue.You will not see SDK versions if you have only installed the runtime.
Applications not using Microsoft.NetCore.App
The affected assembly is also available separately as a NuGet package. If you are not using Microsoft.NetCore.App, you may still be affected if you are referencing the packages listed above.
Direct dependencies
Direct dependencies are discoverable by examining your
csproj
file. They can be fixed by editing the project file or using NuGet to update the dependency.Transitive dependencies
Transitive dependencies occur when you add a package to your project that in turn relies on another package. For example, if Contoso publishes a package
Contoso.Utility
which, in turn, depends onContoso.Internals
and you add theContoso.Utility
package to your project now your project has a direct dependency onContoso.Utility
and, becauseContoso.Utility
depends 'Contoso.Internals', your application gains a transitive dependency on theContoso.Internals
package.Transitive dependencies are reviewable in two ways:
project.assets.json
file contained in the obj directory of your project forcsproj
based projectsThe
project.assets.json
files are the authoritative list of all packages used by your project, containing both direct and transitive dependencies.There are two ways to view transitive dependencies. You can either use Visual Studio’s Solution Explorer, or you can review the
project.assets.json
file).Using Visual Studio Solution Explorer
To use Solution Explorer, open the project in Visual Studio, and then press Ctrl+; to activate the search in Solution Explorer. Search for the vulnerable package and make a note of the version numbers of any results you find.
For example, searching for
Microsoft.AspNetCore.Mvc.Core
in an example project that contains a package that takes a dependency onMicrosoft.AspNetCore.Mvc
shows the following results in Visual Studio 2017:The search results appear as a tree. In the previous results, you can see that a reference to
Microsoft.AspNetCore.Mvc.Core
version 1.1.2 is discovered.Under the Dependencies node is a NuGet node. Under the NuGet node is the list of packages you have directly taken a dependency on and their versions.
In screenshot, the application takes a direct dependency on
Microsoft.AspNetCore.Mvc
.Microsoft.AspNetCore.Mvc
in turn has leaf nodes that list its dependencies and their versions.The
Microsoft.AspNetCore.Mvc
package takes a dependency on a version ofMicrosoft.AspNetCore.Mvc.ApiExplorer
, that in turn takes a dependency on a version ofMicrosoft.AspNetCore.Mvc.Core
.Manually reviewing project.assets.json
Open the project.assets.json file from your project’s obj directory in your editor. We suggest you use an editor that understands JSON and allows you to collapse and expand nodes to review this file.
Visual Studio and Visual Studio Code provide JSON friendly editing.
Search the project.assets.json file for the vulnerable package, using the format
packagename/
for each of the package names from the preceding table. If you find the assembly name in your search:/
.For example, a search result that shows
SSystem.Net.Http/4.3.0
is a reference to version 4.3.0 ofSystem.Net.Http
.If your project.assets.json file includes references to the vulnerable package, then you need to fix the transitive dependencies.
If you have not found any reference to any vulnerable packages, this means either
How do I fix the issue?
Updating the version of Microsoft.NETCore.App
If your host version is a 2.1.x host you must install version 2.1.7 or later of the .NET Core 2.1 runtime, or corresponding .NET Core 2.1 SDK.
If your host version is a 2.2.x you must install version 2.2.1 or later of the .NET Core 2.2 runtime, or corresponding .NET Core 2.2 SDK.
Fixing direct dependencies
Open projectname.csproj in your editor. If you're using Visual Studio, right-click the project and choose Edit projectname.csproj from the context menu, where projectname is the name of your project. Look for
PackageReference
elements. The following shows an example project file:The preceding example has a reference to the vulnerable package, as seen by the single
PackageReference
element. The name of the package is in theInclude
attribute.The package version number is in the
Version
attribute. The previous example shows a single direct dependency onSystem.Net.Http
version 4.3.0To update the version to the secure package, change the version number to the updated package version as listed on the table previously.
In this example, update
System.IO.Pipelines
to the appropriate fixed package number for your major version. Save the csproj file. The example csproj now looks as follows:If you're using Visual Studio and you save your updated csproj file, Visual Studio will restore the new package version.
You can see the restore results by opening the Output window (Ctrl+Alt+O) and changing the Show output from drop-down list to Package Manager.
If you're not using Visual Studio, open a command line and change to your project directory. Execute the
dotnet restore
command to restore the updated dependencies.Now recompile your application. If after recompilation you see a Dependency conflict warning, you must update your other direct dependencies to versions that take a dependency on the updated package.
Fixing transitive dependencies
If your transitive dependency review found references to the vulnerable package, you must add a direct dependency to the updated package to your csproj file to override the transitive dependency.
Open projectname.csproj in your editor. If you're using Visual Studio, right-click the project and choose Edit projectname.csproj from the context menu, where projectname is the name of your project.
Look for
PackageReference
nodes, for example:You must add a direct dependency to the updated version of the vulnerable package by adding it to the csproj file.
You do this by adding a new line to the dependencies section, referencing the fixed version.
For example, if your search showed a transitive reference to a vulnerable
System.ServiceModel.Http
version, you'd add a reference to the fixed package number.After you've added the direct dependency reference, save your csproj file.
If you're using Visual Studio, save your updated csproj file and Visual Studio will restore the new package versions.
You can see the restore results by opening the Output window (Ctrl+Alt+O) and changing the Show output from drop-down list to Package Manager.
If you're not using Visual Studio, open a command line and change to your project directory. Execute the
dotnet restore
command to restore the new dependencies.Rebuilding your application
Finally, you must rebuild your application, test, and redeploy.
Other Information
Reporting Security Issues
If you have found a potential security issue in .NET Core, please email details to secure@microsoft.com. Reports may qualify for the .NET Core Bug Bounty. Details of the .NET Core Bug Bounty including terms and conditions are at https://aka.ms/corebounty.
Support
You can ask questions about this issue on GitHub in the .NET Core or ASP.NET Core organizations. These are located at https://github.com/dotnet/ and https://github.com/aspnet/. The Announcements repo for each product (https://github.com/dotnet/Announcements and https://github.com/aspnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the discussion issue.
Disclaimer
The information provided in this advisory is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.
External Links
CVE-2019-0545
Revisions
V1.1 (January 9, 2019): Correct affected package table.
V1.0 (January 8, 2019): Advisory published.
Version 1.1
Last Updated 2019-01-09
The text was updated successfully, but these errors were encountered: