-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NSwag.MSBuild has security vulnerabilities #2824
Comments
Its probably because it still supports older/outdated .net versions |
Hi, I work on some projects that use NSwag.MSBuild (13.9.4 at present), and that has recently started to be run through Whitesource, and has similar warnings. I'm not convinced there is an actual issue here (given that the tool is being run at build time to generate C# clients for use in applications that have no ASP code or hosting at all at runtime, so I don't how the CVEs about runtime denial of service issues can occur?) However: Looking at the Microsoft.AspNetCore.* binaries installed by the MSBuild package, it looks to me like the 2.2 binaries installed with the .NET version of the tool are older versions than the 2.2 binaries installed with the .NETCore2.2 version of the tool? Looking at the change history, the netcoreapp2.2 build was updated in 6b35c3e and that mentions CVE-2019-1075 (which is one of the issues that Whitesource mentions), so I wonder if it would be possible to update the .net461 references at
in a similar way? These are the suggestions from Whitesource for reference |
Hi @AndrewKnieriem and @Numpsy, I ran into the same issue with WhiteSource. May I ask what you ended up doing to work around this? @RicoSuter Any plans on updating the dependencies as @Numpsy mentioned? Thanks! |
Hello! Any updates? Thanks! |
I haven't worked on the project I was using NSwag on for a bit and so haven't tried with the current versions, but I have an idea that the .NET 4.x version of NSwag.MSBuild was changed to use Asp.Net Core 2.1 rather than 2.2 at some point (as 2.1 was LTS, and was the most recent still supported version that still worked on .NET Framework?) |
Based on end-of-life policy could probably drop |
One of the issues might have been that Asp.NetCore 2.1 was the last LTS version that supported .NET Framework 4.x, so if you want to support .NET Framework you need to keep using the old libraries? (I can't recall off hand if any of these CVEs were still present in the last 2.1 release or if they were all fixed there though) Alas I think Whitesource might complain about old versions of libraries being present in the package, even if the consuming application only actually uses the .NET 5/6 version or if the libs aren't even used in a way that is effected by the vulnerabilities :-( |
On the subject of Whitesource / Mend complaints - version 13.20.0 of NSwag.MSBuild still contains these three: It's quite possible that none of these issues actually exist in NSwag.MSBuild (denial of service issues in websockets and such) and some of these issues might be eased by the removal of the .NET Core 2.1 builds from the package, but - It looks like there are still references to the 2.1 versions of some Microsoft.AspNetCore packages for use in .NET 4.6.2 targets (https://github.com/RicoSuter/NSwag/blob/a432103946f13f44807b12ee63333dec22f28a3a/src/NSwag.Commands/NSwag.Commands.csproj#L42C17-L42C17) and there are newer versions of some of the the 2.x libs that get packaged in the MSBuild nuget package, so maybe all the libs referenced by the 4.6.2 targets could be updated to the latest versions? One specific example - the 14.0.0-preview005 package contains a copy of Microsoft.AspNetCore.Server.Kestrel.Core.dll version 2.1.3 which is listed on https://www.nuget.org/packages/Microsoft.AspNetCore.Server.Kestrel.Core/ as having high severity vulnerabilities, and there is a newer 2.1.25 version that is listed as being clean. |
I'll keep an eye on the Mend reports, but as it stands it looks like the .NET 4.6.2 build of the Console projects still use the ASP.NetCore 2.1 libs - e.g https://github.com/RicoSuter/NSwag/blob/e078e67b8c74c43b90c46c77a233ab75c248d622/src/NSwag.Commands/NSwag.Commands.csproj#L27C15-L27C15 |
As a general side thought on this, together with #4502 - If things get built with the .NET 8 SDK, would there be any value in enabling the new auditing features in NuGet - https://devblogs.microsoft.com/dotnet/announcing-dotnet-8-preview-4/#enabling-security-auditing ? |
So it looks like NSwag.MSBuild 14.x is not get flagged by Mend/WhiteSource any more after #4561 is merged. |
The .NET Framework version of the tool in 14.0.0 contains a copy of Maybe a similar situation with |
@Numpsy Yes, looks like it is transitional reference. Can be fixed by explicitly referencing it from the project. Can you get a list of all transitional references which need to be updated, from your scanner? But CVE-2019-0548 looks totally ridiculous in this case:
|
Alas, Mend doesn't have any 'intelligence' or context - it's just 'the library is here, therefore theres a problem', even if it's things with IIS or websockets or similar that shouldn't effect a command line tool :-(
Mend is a bit lacking in detailed information here, but fortunately if you're using the .NET 8 SDK and a current Visual Studio 2022 version, the NuGet client will tell you itself: I'm just trying a PR to update the ASP ones. |
On a related note, if you enable nuget package auditing in the solution, e.g Numpsy@264d3db then you get warnings from command line builds as well, which may or may not be useful for CI builds? (Or maybe GitHub Actions has something built in to do it, I don't know) There are a few other warnings in the solution on top of the ones mentioned here, e.g. So i'm not sure if there's anything else that could be checked separately. |
nswag.msbuild.13.4.2.nupkg has vulnerabilities CVE-2019-1075, CVE-2019-0548, CVE-2019-0564, and CVE-2017-0247.
Related to Microsoft Security Advisory 4021279: Vulnerabilities in .NET Core, ASP.NET Core Could Allow Elevation of Privilege.
These vulnerabilities were identified through my company's license of WhiteSource, and as such we can't use this library in production with these issues in place.
The text was updated successfully, but these errors were encountered: