Microsoft Security Advisory CVE-2022-30184 | .NET Information Disclosure Vulnerability

[JonDouglas]

Microsoft Security Advisory CVE-2022-30184 | .NET Information Disclosure Vulnerability

Executive summary

Microsoft is releasing this security advisory to provide information about a vulnerability in .NET 6.0 and .NET Core 3.1, NuGet (NuGet.exe, NuGet.Commands, NuGet.CommandLine, NuGet.CommandLine.XPlat version range from 3.5.0 to 6.2.0). This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.

A vulnerability exists in .NET 6.0, .NET Core 3.1, and NuGet clients (NuGet.exe, NuGet.Commands, NuGet.CommandLine, NuGet.CommandLine.XPlat version range from 3.5.0 to 6.2.0) where a nuget.org credential could be leaked.

Discussion

Announcement for this issue can be found at NuGet/Announcements#62

Mitigation factors

Microsoft has not identified any mitigating factors for this vulnerability.

Affected software

NuGet & NuGet Packages

• Any NuGet.exe, NuGet.Commands, NuGet.CommandLine, NuGet.CommandLine.XPlat 6.2.0 version or earlier.
• Any NuGet.exe, NuGet.Commands, NuGet.CommandLine, NuGet.CommandLine.XPlat 6.0.1 version or earlier.
• Any NuGet.exe, NuGet.Commands, NuGet.CommandLine, NuGet.CommandLine.XPlat 5.11.1 version or earlier.
• Any NuGet.exe, NuGet.Commands, NuGet.CommandLine, NuGet.CommandLine.XPlat 5.9.1 version or earlier.
• Any NuGet.exe, NuGet.Commands, NuGet.CommandLine, NuGet.CommandLine.XPlat 5.7.1 version or earlier.
• Any NuGet.exe, NuGet.Commands, NuGet.CommandLine, NuGet.CommandLine.XPlat 5.2.0 version or earlier.
• Any NuGet.exe, NuGet.Commands, NuGet.CommandLine, NuGet.CommandLine.XPlat 4.9.4 version or earlier.

GitHub Advisory

.NET SDK(s)

• Any .NET 6.0 application running on .NET 6.0.5 or earlier.
• Any .NET 3.1 application running on .NET Core 3.1.25 or earlier.

How do I know if I am affected?

If you have a NuGet.exe, NuGet package, or .NET SDK with a version listed in affected software, you're exposed to the vulnerability.

How do I fix the issue?

To fix the issue, please install the latest version of .NET 6.0 or .NET Core 3.1 and NuGet (NuGet.exe, NuGet.Commands, NuGet.CommandLine, NuGet.CommandLine.XPlat version 4.9.5, 5.7.2, 5.9.2, 5.11.2, 6.0.2, 6.2.1). If you have installed one or more .NET SDKs through Visual Studio, Visual Studio will prompt you to update Visual Studio, which will also update your .NET SDKs.

You can get the version of NuGet.exe by running the nuget command. You should see an output like the following:

NuGet Version: 6.0.0.280

usage: NuGet <command> [args] [options]

Type 'NuGet help <command>' for help on a specific command.

To install additional .NET Core runtimes or SDKs:

  https://www.nuget.org/downloads

If you're using NuGet.exe 6.2.0 or lower, you should download and install 6.2.1 from https://dist.nuget.org/win-x86-commandline/v6.2.1/nuget.exe.

If you're using NuGet.exe 6.0.1 or lower, you should download and install 6.0.2 from https://dist.nuget.org/win-x86-commandline/v6.0.2/nuget.exe.

If you're using NuGet.exe 5.11.1 or lower, you should download and install 5.11.2 from https://dist.nuget.org/win-x86-commandline/v5.11.2/nuget.exe.

If you're using NuGet.exe 5.9.1 or lower, you should download and install 5.9.2 from https://dist.nuget.org/win-x86-commandline/v5.9.2/nuget.exe.

If you're using NuGet.exe 5.7.1 or lower, you should download and install 5.7.2 from https://dist.nuget.org/win-x86-commandline/v5.7.2/nuget.exe.

If you're using NuGet.exe 5.2.0 or lower, you should download and install 5.2.1 from https://dist.nuget.org/win-x86-commandline/v5.2.1/nuget.exe.

If you're using NuGet.exe 4.9.4 or lower, you should download and install 4.9.5 from https://dist.nuget.org/win-x86-commandline/v4.9.5/nuget.exe.

You can list the versions you have installed by running the dotnet --info command. You should see an output like the following:

.NET Core SDK (reflecting any global.json):

 Version:   6.0.300

 Commit:    8473146e7d



Runtime Environment:

 OS Name:     Windows

 OS Version:  10.0.18363

 OS Platform: Windows

 RID:         win10-x64

 Base Path:   C:\Program Files\dotnet\sdk\6.0.300\



Host (useful for support):

  Version: 6.0.5

  Commit:  8473146e7d



.NET Core SDKs installed:

  6.0.300 [C:\Program Files\dotnet\sdk]



.NET Core runtimes installed:

  Microsoft.AspNetCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]

  Microsoft.NETCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

  Microsoft.WindowsDesktop.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]



To install additional .NET Core runtimes or SDKs:

  https://aka.ms/dotnet-download

If you're using .NET Core 6.0, you should download and install Runtime 6.0.6 or SDK 6.0.106 (for Visual Studio 2022 v17.0) or SDK 6.0.301 (for Visual Studio 2022 v17.2) from https://dotnet.microsoft.com/download/dotnet-core/6.0.

If you're using .NET Core 3.1, you should download and install Runtime 3.1.26 or SDK 3.1.420 (for Visual Studio 2019 v16.9 or Visual Studio 2011 16.11 or Visual Studio 2022 17.0 or Visual Studio 2022 17.1) from https://dotnet.microsoft.com/download/dotnet-core/3.1

.NET 6.0 and .NET Core 3.1 updates are also available from Microsoft Update. To access this either type "Check for updates" in your Windows search, or open Settings, choose Update & Security and then click Check for Updates.

Once you have installed the updated runtime or SDK, restart your apps for the update to take effect.

Additionally, if you've deployed self-contained applications targeting any of the impacted versions, these applications are also vulnerable and must be recompiled and redeployed.

Other Information

Reporting Security Issues

If you have found a potential security issue in .NET 5 or .NET 6.0, please email details to secure@microsoft.com. Reports may qualify for the Microsoft .NET Core & .NET 5 Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty.

Support

You can ask questions about this issue on GitHub in the .NET GitHub organization. The main repo is located at https://github.com/NuGet/NuGet.Client. The Announcements repo will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked 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-2022-30184

Revisions

V1.0 (June 14, 2022): Advisory published.

Version 1.0

Last Updated 2022-06-14

[mungojam]

It seems really unclear on what the impact is here. 'if you have a nuget package...then you are affected'. If that is the case then do we need to republish all historical nuget packages that were created using the affected versions?

[JonDouglas]

@mungojam It should say "in the affected versions". Does that help bring clarity? The GitHub advisory will also help with version ranges.

Here is the GitHub reviewed advisory too as of an hour ago:

GHSA-3885-8gqc-3wpf

[bgever]

Does this also affect NuGet bundled with Mono? (dependency of Visual Studio for Mac and VSCode OmniSharp)

Edit: Seems so; https://github.com/mono/mono/releases/tag/mono-6.12.0.182

[mungojam]

@mungojam It should say "in the affected versions". Does that help bring clarity? The GitHub advisory will also help with version ranges.

I had assumed that, but it's useful to add. My query is more about the resolution. If we have built many nuget packages and packages versions with the affected versions, should we need to republish all of those nuget package versions? The implication is yes but it only says to update your version of nuget/.net SDK, not about republishing old versions.

[mungojam]

Sorry I'm struggling to articulate my questions. Here are a few more related ones:

1. Is it that we will have leaked credentials within the nupkg files that we have historically created? (Hence we need to republish existing versions)
2. Does it only affect nuget.org credentials or would GitHub packages credentials also be affected? We have never published to nuget.org, only GitHub packages, so would we be impacted?

[KalleOlaviNiemitalo]

The most important part of the fix in NuGet 6.2.1 seems to be NuGet/NuGet.Client@ec6e62a#diff-9e678e6dcc29381eb7c564f0e75ffc3ffc35458eca412c35b6404340b698d074R58-R65. If you used NuGet (e.g. nuget push) to access a server but had not configured an API key for it, then NuGet might have chosen your nuget.org API key instead and disclosed it to that server in API requests. It would not leak the API key as part of the nupkg file. It would not leak a GitHub packages API key in a similar way, because the code specifically looks for an API key for NuGetConstants.DefaultGalleryServerUrl, i.e. "https://www.nuget.org".

Anyway, if you suspect your credential might have leaked, it would be more prudent to replace the credential than republish the packages.

[mungojam]

@KalleOlaviNiemitalo that's helpful to know if it is 'nuget push' that is affected, not 'nuget pack'. We don't have nuget.org credentials so those won't be leaked, however it's not clear if GitHub packages credentials could also have been leaked (the advisory only mentions nuget.org credentials but it seems logical that any nuget server credentials might be leaked)

[blowdart]

To expand on the vulnerability (we don't go into details on CVEs, hence the confusion here, and everyone defers to me on whether details need to be shared, hence the delay in a response.)

The problem would have occured when you publish a package to nuget.org using any of the affected nuget clients.

It is limited to nuget.org api credentials and doesn't affect github or azdo credentials. It is only the pushing operation that could expose api credentials, nothing gets dropped into your nupkgs, you don't have to rebuild packages or republish.

If you're concerned, rotate your api credentials and look at your published packages and make sure you recognise all of them. We haven't detected any attacks, but you never know.

I hope this is enough detail @mungojam, if it's not please tag me in a response.

[KalleOlaviNiemitalo]

Was this issue discovered by someone specifically looking for vulnerabilities, or by someone working on the code for other purposes?

[blowdart]

As part of a variant analysis

[ben-at-sparq]

It seems there is a breaking change in NuGet 6.0.2/.NET SDK 6.0.301 where the nuget.config setting "globalPackagesFolder" isn't being used.
Our build server is behind a firewall and cannot connect to nuget.org, so all packages are checked into source control in a local folder.
These builds work fine if we use global.json to enforce usage of SDK 6.0.300 but fail with a timeout using 6.0.301 which still tries to connect to nuget.org
Anyone else experienced this since updating?

[ben-at-sparq]

It seems there is a breaking change in NuGet 6.0.2/.NET SDK 6.0.301 where the nuget.config setting "globalPackagesFolder" isn't being used. Our build server is behind a firewall and cannot connect to nuget.org, so all packages are checked into source control in a local folder. These builds work fine if we use global.json to enforce usage of SDK 6.0.300 but fail with a timeout using 6.0.301 which still tries to connect to nuget.org Anyone else experienced this since updating?

OK so turns out it's not finding the 6.0.6 runtime. If I clear the package sources the error message is pretty clear.

If I change the runtime to 6.0.5 and check in those runtime binaries it works - but I don't want to specify a version of the runtime to use.

Was this runtime package mistakenly left out of SDK 6.0.301?

[cremor]

I just found this via microsoft/vstest#4409. It seems like the affected reference was https://www.nuget.org/packages/NuGet.Frameworks/5.11.0.
Why is this package (and other affected packages) unlisted on NuGet instead of being marked as having a security vulnerability (or at least marked as deprecated)? If they would have been marked correctly, the commands dotnet list package --include-transitive --vulnerable or dotnet list package --include-transitive --deprecated would have found them.

This will be even more important starting with .NET 8 when dotnet restore and dotnet add package will automatically do a vulnerable check.