Confusion with security updates not showing resolved from Nessus

[brentil]

I do some basic development with VS so I'm familiar with it but I mainly do the IT side of things. Keeping user's systems updated and doing security scans to make sure everything is updated. For a couple months though I've been having issues reconciling what the Nessus security scanner is saying is on our developers systems and vulnerable versus what the systems show as being installed. All of our systems are Windows 10 running Visual Studio 2017 15.7.6. I've seen the other threads about how .NET Core old versions get left behind so on a test system I went in and uninstalled everything but the latest version which was "Microsoft .NET Core SDK 2.1.202 (x64)" and did a fresh Nessus scan and I still get findings.

Microsoft ASP.NET Core Privilege Escalation (March 2018)

Path : C:\Program Files\dotnet\ Installed version : 2.0.13103.0

Package : Microsoft.AspNetCore.Server.Kestrel.Core Path : C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.server.kestrel.core\2.0.0\lib\netstandard2.0\Microsoft.AspNetCore.Server.Kestrel.Core.dll Installed version : 2.0.0.17205 Fixed version : 2.0.2

Package : Microsoft.AspNetCore.Server.Kestrel.Core Path : C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.server.kestrel.core\2.0.1\lib\netstandard2.0\Microsoft.AspNetCore.Server.Kestrel.Core.dll Installed version : 2.0.1.17303 Fixed version : 2.0.2

Package : Microsoft.AspNetCore.HttpOverrides Path : C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.httpoverrides\2.0.0\lib\netstandard2.0\Microsoft.AspNetCore.HttpOverrides.dll Installed version : 2.0.0.17205 Fixed version : 2.0.2

Package : Microsoft.AspNetCore.HttpOverrides Path : C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.httpoverrides\2.0.1\lib\netstandard2.0\Microsoft.AspNetCore.HttpOverrides.dll Installed version : 2.0.1.17303 Fixed version : 2.0.2

Security Updates for Microsoft .NET core and ASP.NET (Bypass) (July 2018)

Path : C:\Program Files\dotnet\ Installed version : 2.0.13103.0

Package : Microsoft.AspNetCore.Identity Path : C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.identity\2.0.0\lib\netstandard2.0\Microsoft.AspNetCore.Identity.dll Installed version : 2.0.0.17205 Fixed version : 2.0.4

Package : Microsoft.AspNetCore.Identity Path : C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.identity\2.0.1\lib\netstandard2.0\Microsoft.AspNetCore.Identity.dll Installed version : 2.0.1.17303 Fixed version : 2.0.4

Package : Microsoft.AspNetCore.Identity Path : C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.identity\2.0.2\lib\netstandard2.0\Microsoft.AspNetCore.Identity.dll Installed version : 2.0.2.18051 Fixed version : 2.0.4

Package : Microsoft.AspNetCore.Identity Path : C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.identity\2.0.3\lib\netstandard2.0\Microsoft.AspNetCore.Identity.dll Installed version : 2.0.3.18114 Fixed version : 2.0.4

Security Updates for Microsoft .NET core and ASP.NET (DoS) (July 2018)

Path : C:\Program Files\dotnet\ Installed version : 2.0.13103.0

Package : Microsoft.AspNetCore.Server.Kestrel.Core Path : C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.server.kestrel.core\2.0.0\lib\netstandard2.0\Microsoft.AspNetCore.Server.Kestrel.Core.dll Installed version : 2.0.0.17205 Fixed version : 2.0.4

Package : Microsoft.AspNetCore.Server.Kestrel.Core Path : C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.server.kestrel.core\2.0.1\lib\netstandard2.0\Microsoft.AspNetCore.Server.Kestrel.Core.dll Installed version : 2.0.1.17303 Fixed version : 2.0.4

Package : Microsoft.AspNetCore.Server.Kestrel.Core Path : C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.server.kestrel.core\2.0.2\lib\netstandard2.0\Microsoft.AspNetCore.Server.Kestrel.Core.dll Installed version : 2.0.2.18051 Fixed version : 2.0.4

Package : Microsoft.AspNetCore.Server.Kestrel.Core Path : C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.server.kestrel.core\2.0.3\lib\netstandard2.0\Microsoft.AspNetCore.Server.Kestrel.Core.dll Installed version : 2.0.3.18114 Fixed version : 2.0.4

I then found that the latest .NET Core wasn't even shipping with the VS updates for 15.7.x and won't be till 15.8.x so I got the latest "Microsoft .NET Core SDK 2.1.302 (x64)" and installed it and removed 2.1.202 from the system. I then did another fresh Nessus scan and it still continues to find vulnerable versions on the system. I honestly don't know the inner workings of .NET Core enough but it looks like old DLLs are being moved into an archive folder but still being left on the system. The NuGetFallbackFolder was new as of the 2.1.302 where in the 2.1.202 they were still in the main folders.

Microsoft ASP.NET Core Privilege Escalation (March 2018)

Path : C:\Program Files\dotnet\ Installed version : 2.1.13029.0

Package : Microsoft.AspNetCore.Server.Kestrel.Core Path : C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.server.kestrel.core\2.0.0\lib\netstandard2.0\Microsoft.AspNetCore.Server.Kestrel.Core.dll Installed version : 2.0.0.17205 Fixed version : 2.0.2 ...

Security Updates for Microsoft .NET core and ASP.NET (Bypass) (July 2018)

Path : C:\Program Files\dotnet\ Installed version : 2.1.13029.0

Package : Microsoft.AspNetCore.Identity Path : C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.identity\2.0.0\lib\netstandard2.0\Microsoft.AspNetCore.Identity.dll Installed version : 2.0.0.17205 Fixed version : 2.0.4 ...

Security Updates for Microsoft .NET core and ASP.NET (DoS) (July 2018)

Path : C:\Program Files\dotnet\ Installed version : 2.1.13029.0

Package : Microsoft.AspNetCore.Server.Kestrel.Core Path : C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.server.kestrel.core\2.0.0\lib\netstandard2.0\Microsoft.AspNetCore.Server.Kestrel.Core.dll Installed version : 2.0.0.17205 Fixed version : 2.0.4 ...

All that to say as a small shop with limited resources this is confusing and complicated. Keeping VS 2017 up to date on our users systems is time consuming manual process now. Not being able to provide clean compliance scans after an update has been applied to makes this even more time consuming as I have to track down what's going on and then write justification for every item.

[Petermarcu]

Adding Damian,

Those issues are flagging Asp.net binaries in two different locations.

1. The runtime "store". This location is cumulative and things in here are used by applications based on exact version match. If anything in here is getting used, the application using it needs to be updated.

2. NugetFallbackFolder, this is a cache of nuget packages. Similar to above, the only way the version there will be used is if an application references it and in that case, the application needs to be updated.

Damian, anything to add?

-------- Original message -------- From: Leith Tussing notifications@github.com Date: 8/8/18 1:03 PM (GMT-05:00) To: dotnet/core core@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: [dotnet/core] Confusion with security updates not showing resolved from Nessus (#1842)

I do some basic development with VS so I'm familiar with it but I mainly do the IT side of things. Keeping user's systems updated and doing security scans to make sure everything is updated. For a couple months though I've been having issues reconciling what the Nessus security scanner is saying is on our developers systems and vulnerable versus what the systems show as being installed. All of our systems are Windows 10 running Visual Studio 2017 15.7.6. I've seen the other threads about how .NET Core old versions get left behind so on a test system I went in and uninstalled everything but the latest version which was "Microsoft .NET Core SDK 2.1.202 (x64)" and did a fresh Nessus scan and I still get findings.

Microsoft ASP.NET Core Privilege Escalation (March 2018)

Path : C:\Program Files\dotnet Installed version : 2.0.13103.0

Package : Microsoft.AspNetCore.Server.Kestrel.Core Path : C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.server.kestrel.core\2.0.0\lib\netstandard2.0\Microsoft.AspNetCore.Server.Kestrel.Core.dll Installed version : 2.0.0.17205 Fixed version : 2.0.2

Package : Microsoft.AspNetCore.Server.Kestrel.Core Path : C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.server.kestrel.core\2.0.1\lib\netstandard2.0\Microsoft.AspNetCore.Server.Kestrel.Core.dll Installed version : 2.0.1.17303 Fixed version : 2.0.2

Package : Microsoft.AspNetCore.HttpOverrides Path : C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.httpoverrides\2.0.0\lib\netstandard2.0\Microsoft.AspNetCore.HttpOverrides.dll Installed version : 2.0.0.17205 Fixed version : 2.0.2

Package : Microsoft.AspNetCore.HttpOverrides Path : C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.httpoverrides\2.0.1\lib\netstandard2.0\Microsoft.AspNetCore.HttpOverrides.dll Installed version : 2.0.1.17303 Fixed version : 2.0.2

Security Updates for Microsoft .NET core and ASP.NET (Bypass) (July 2018)

Path : C:\Program Files\dotnet Installed version : 2.0.13103.0

Package : Microsoft.AspNetCore.Identity Path : C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.identity\2.0.0\lib\netstandard2.0\Microsoft.AspNetCore.Identity.dll Installed version : 2.0.0.17205 Fixed version : 2.0.4

Package : Microsoft.AspNetCore.Identity Path : C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.identity\2.0.1\lib\netstandard2.0\Microsoft.AspNetCore.Identity.dll Installed version : 2.0.1.17303 Fixed version : 2.0.4

Package : Microsoft.AspNetCore.Identity Path : C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.identity\2.0.2\lib\netstandard2.0\Microsoft.AspNetCore.Identity.dll Installed version : 2.0.2.18051 Fixed version : 2.0.4

Package : Microsoft.AspNetCore.Identity Path : C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.identity\2.0.3\lib\netstandard2.0\Microsoft.AspNetCore.Identity.dll Installed version : 2.0.3.18114 Fixed version : 2.0.4

Security Updates for Microsoft .NET core and ASP.NET (DoS) (July 2018)

Path : C:\Program Files\dotnet Installed version : 2.0.13103.0

Package : Microsoft.AspNetCore.Server.Kestrel.Core Path : C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.server.kestrel.core\2.0.0\lib\netstandard2.0\Microsoft.AspNetCore.Server.Kestrel.Core.dll Installed version : 2.0.0.17205 Fixed version : 2.0.4

Package : Microsoft.AspNetCore.Server.Kestrel.Core Path : C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.server.kestrel.core\2.0.1\lib\netstandard2.0\Microsoft.AspNetCore.Server.Kestrel.Core.dll Installed version : 2.0.1.17303 Fixed version : 2.0.4

Package : Microsoft.AspNetCore.Server.Kestrel.Core Path : C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.server.kestrel.core\2.0.2\lib\netstandard2.0\Microsoft.AspNetCore.Server.Kestrel.Core.dll Installed version : 2.0.2.18051 Fixed version : 2.0.4

Package : Microsoft.AspNetCore.Server.Kestrel.Core Path : C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.server.kestrel.core\2.0.3\lib\netstandard2.0\Microsoft.AspNetCore.Server.Kestrel.Core.dll Installed version : 2.0.3.18114 Fixed version : 2.0.4

I then found that the latest .NET Core wasn't even shipping with the VS updates for 15.7.x and won't be till 15.8.x so I got the latest "Microsoft .NET Core SDK 2.1.302 (x64)" and installed it and removed 2.1.202 from the system. I then did another fresh Nessus scan and it still continues to find vulnerable versions on the system. I honestly don't know the inner workings of .NET Core enough but it looks like old DLLs are being moved into an archive folder but still being left on the system. The NuGetFallbackFolder was new as of the 2.1.302 where in the 2.1.202 they were still in the main folders.

Microsoft ASP.NET Core Privilege Escalation (March 2018)

Path : C:\Program Files\dotnet Installed version : 2.1.13029.0

Package : Microsoft.AspNetCore.Server.Kestrel.Core Path : C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.server.kestrel.core\2.0.0\lib\netstandard2.0\Microsoft.AspNetCore.Server.Kestrel.Core.dll Installed version : 2.0.0.17205 Fixed version : 2.0.2 ...

Security Updates for Microsoft .NET core and ASP.NET (Bypass) (July 2018)

Path : C:\Program Files\dotnet Installed version : 2.1.13029.0

Package : Microsoft.AspNetCore.Identity Path : C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.identity\2.0.0\lib\netstandard2.0\Microsoft.AspNetCore.Identity.dll Installed version : 2.0.0.17205 Fixed version : 2.0.4 ...

Security Updates for Microsoft .NET core and ASP.NET (DoS) (July 2018)

Path : C:\Program Files\dotnet Installed version : 2.1.13029.0

Package : Microsoft.AspNetCore.Server.Kestrel.Core Path : C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.server.kestrel.core\2.0.0\lib\netstandard2.0\Microsoft.AspNetCore.Server.Kestrel.Core.dll Installed version : 2.0.0.17205 Fixed version : 2.0.4 ...

All that to say as a small shop with limited resources this is confusing and complicated. Keeping VS 2017 up to date on our users systems is time consuming manual process now. Not being able to provide clean compliance scans after an update has been applied to makes this even more time consuming as I have to track down what's going on and then write justification for every item.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fcore%2Fissues%2F1842&data=02%7C01%7Cpeter.marcu%40microsoft.com%7C7d47e072d0714554cbc408d5fd50ce0e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636693445858682545&sdata=skQWaP2pFQRNSzTz6dLt%2FesTlfDAXsRe4Iy1UT0hXU8%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAH2OB6TVCSmSDSeboBUTCeWvLnx-w9PIks5uOxnHgaJpZM4V0UHm&data=02%7C01%7Cpeter.marcu%40microsoft.com%7C7d47e072d0714554cbc408d5fd50ce0e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636693445858692549&sdata=G8VK3vJUdhOkYMY51HMKyzqjTjnoJttPcQAE1dtEuxk%3D&reserved=0.

[blowdart]

The problem I guess is nessus has no way to tell if applications are targetting the older pieces, nor does anyone else, you'd have to delete that version from the store / fallback folder and see. Nor does nessus realise there are updated versions available for things that don't version match.

There's nothing we can do here unfortunately.

[DamianEdwards]

There's a few things at play here which I agree makes this more difficult than it ideally could (should) be. For what it's worth, these are things we're actively looking to improve in .NET Core 3.0 and beyond, but let me try to explain the moving pieces as they are now.

As Peter said, there are two locations being flagged here by the scan for contain vulnerable pieces: the "runtime store", and the NuGet Fallback Folder. They're both used for different things at different times, but by themselves don't necessarily indicate that apps are using those versions and are thus vulnerable. Furthermore, how these things are used is different between .NET Core 1.x, 2.0, and 2.1 projects. It's different again if your ASP.NET Core application is targeting and thus running on .NET Framework, rather than on .NET Core.

Of these two locations, only the "runtime store" is tracked by installers, such that when you uninstall the files go away. The NuGet Fallback Folder is not removed when you uninstall .NET Core SDK versions and so older files will remain there until they're removed manually. The other important difference is that the "runtime store" is used by deployed applications at runtime (as they name implies), whereas the NuGet Fallback Folder is only used by projects during development. Once the project is published (and thus becomes an application) it either takes the assemblies it needs with it, or gets them from the "runtime store" (in 2.0) or a "shared framework" (in 2.1 and beyond).

In .NET Core 1.x and all .NET Framework projects, ASP.NET Core assemblies come from NuGet packages and are published with your application. The version you get is determined by the version of the package you reference in the project. So to ensure your project is up to date, you need to update the package versions referenced in the csproj file, then build/publish and redeploy it.

In .NET Core 2.0 projects, the ASP.NET Core assemblies come from NuGet packages at design/compile time, but typically aren't published with your application. Instead, at runtime they come from the "runtime store". However, the version the application needs is still dictated by the package version specified in the project file, so it's the same process for ensuring the project is up to date: update the package versions referenced in the csproj file, then build/publish and redeploy it. It also requires the additional step of ensuring the "runtime store" update is installed on the machines where the deployed application will actually run (i.e. the server).

In .NET Core 2.1 projects, the ASP.NET Core assemblies still come from NuGet packages at design/compile time, and they still aren't published with your application, but at runtime they come from a "shared framework" (located under C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App). The key difference with this is that you don't need to change the version of ASP.NET Core in the project file, but rather you can leave it completely blank (e.g. <PackageReference Include="Microsoft.AspNetCore.App" />) . The build process will then transparently set that to the "baseline" version (currently 2.1.1) which is the same version you'll find in the NuGet Fallback Folder (so that the restore can complete without going online). However, at runtime, the application will roll-forward onto the latest patch version of the shared framework it finds on the machine (currently 2.1.2). This means that as patches are released, the NuGet Fallback Folder doesn't need new packages (as the baseline stays at 2.1.1), you just need to get a new shared framework (which of course is included in the updated SDKs). It also means on the servers, you simply need to install patched shared frameworks as they're released (2.1.2, 2.1.3, 2.1.4, etc.) and all apps on that server that were compiled against 2.1.0 will automatically roll forward onto the patched runtime when they next restart (rather than having to have their project files updated, build/published, and redeployed).

The end result of all this is that vulnerable assemblies will continue to be found in the NuGet Fallback Folder for the life of 2.x, but that doesn't mean they're necessarily used at runtime by your applications. Scanning of machines that install the SDK will continue to show these results, but scanning of servers (where you typically only install runtime assets) should be more inline with what one would expect.

I hope that helps.

[brentil]

I appreciate the feedback, it provides information I can use for documentation for these findings. When doing scans for certain organizations there is no allowance to alter the scans to either tailor out certain findings or to change their severity. A good example is the DoD which tracks .NET Core in their IAVMs so every one of these findings is a ream of documentation monthly to explain and work on mitigating. They don't care that it might not be targeted for use but it exists on the system at all.

[leecow]

The end result of all this is that vulnerable assemblies will continue to be found in the NuGet Fallback Folder for the life of 2.x, but that doesn't mean they're necessarily used at runtime by your applications.

It seems like we should determine if there are reasonable ways to not leave vulnerable assemblies in the FallbackFolder.

/cc @natemcmaster

[DamianEdwards]

This will be fixed with the changes coming in 3.0, but fixing in 2.1.x is challenging without giving up other things, e.g. offline restore.

[Petermarcu]

I'm going to close this issue now. I think we all understand how this works and that its going to be addressed in a future release.

[The-Everett]

Since I didn't need this version any longer, I installed SDK 2.1.202, then uninstalled it. The /store directory is gone now, so Nessus doesn't report it any longer.

[asijoshi]

I was facing a similar issue with the Nessus security scan reporting the previous versions having vulnerabilities.

To resolve this, I installed the updated version of .Net Core SDK i.e. .Net Core SDK 2.1.522 and uninstalled .Net Core SDK 2.1.202.

The vulnerabilities were remediated and not reported in the next scan report.

Good luck.