CastleCore using an old version of System.Net.Http which is vulnerable to "DoS", "Spoofing", "Privilege Escalation", "Authentication Bypass" and "Information Exposure"

[sydseter]

The following vulnerable libraries were found: System.Net.Http@4.3.0 and System.Text.RegularExpressions@4.3.0

All issues for System.Net.Http@4.3.0 have been fixed in 4.3.4.
All issues for System.Text.RegularExpressions@4.3.0 have been fixed in 4.3.1

These are the vulnerabilities associated vulnerable paths:

✗ Denial of Service (DoS) [High Severity]https://snyk.io/vuln/SNYK-DOTNET-SYSTEMNETHTTP-60045 in System.Net.Http@4.3.0
introduced by:
Castle.Core@4.4.0 > NETStandard.Library@1.6.1 > System.Net.Http@4.3.0
This issue was fixed in versions: 4.1.2, 4.3.2
✗ Improper Certificate Validation [High Severity]https://snyk.io/vuln/SNYK-DOTNET-SYSTEMNETHTTP-60046 in System.Net.Http@4.3.0
introduced by:
Castle.Core@4.4.0 > NETStandard.Library@1.6.1 > System.Net.Http@4.3.0
This issue was fixed in versions: 4.1.2, 4.3.2
✗ Privilege Escalation [High Severity]https://snyk.io/vuln/SNYK-DOTNET-SYSTEMNETHTTP-60047 in System.Net.Http@4.3.0
introduced by:
Castle.Core@4.4.0 > NETStandard.Library@1.6.1 > System.Net.Http@4.3.0
This issue was fixed in versions: 4.1.2, 4.3.2
✗ Authentication Bypass [Medium Severity]https://snyk.io/vuln/SNYK-DOTNET-SYSTEMNETHTTP-60048 in System.Net.Http@4.3.0
introduced by:
Castle.Core@4.4.0 > NETStandard.Library@1.6.1 > System.Net.Http@4.3.0
This issue was fixed in versions: 4.1.2, 4.3.2
✗ Information Exposure [High Severity]https://snyk.io/vuln/SNYK-DOTNET-SYSTEMNETHTTP-72439 in System.Net.Http@4.3.0
introduced by:
Castle.Core@4.4.0 > NETStandard.Library@1.6.1 > System.Net.Http@4.3.0
This issue was fixed in versions: 2.0.20710, 4.0.1-beta-23225, 4.1.4, 4.3.4
✗ Regular Expression Denial of Service (ReDoS) [High Severity]https://snyk.io/vuln/SNYK-DOTNET-SYSTEMTEXTREGULAREXPRESSIONS-174708 in System.Text.RegularExpressions@4.3
.0
introduced by:
Castle.Core@4.4.0 > NETStandard.Library@1.6.1 > System.Text.RegularExpressions@4.3.0
Castle.Core@4.4.0 > NETStandard.Library@1.6.1 > System.Xml.ReaderWriter@4.3.0 > System.Text.RegularExpressions@4.3.0
This issue was fixed in versions: 4.3.1

[Havunen]

I cant see castle core 4.4.1 referencing .netstandard 1.6 library? Is this issue solved in 4.4.1? Any estimate for v5 release?

[Havunen]

Because I couldn't find any fix to this I released my own version of NSubstitute and Castle.Core to nuget which target only .NET 5 and .NET 6 code.
They are available in: https://www.nuget.org/packages/NSubstituteNet6/ and https://www.nuget.org/packages/CastleCoreNet6/

[Jevonius]

@jonorossi - I'm in the middle of updating our codebase to mitigate this issue; do you have an idea of ETA for v5.0.0? If not, should I create a PR for a v4.4.2 with just these updates in place?

Edit: Just spotted #604 🤦‍♂️

[jonorossi]

These are transitive dependencies of a .NET platform package that Castle Core doesn't even reference. Why can't your application do the same thing rather than hacking this into Castle Core if Microsoft won't patch the package anymore? Any .NET library still targeting .NET Standard 1.x would be incorrectly reported by your security analysis tool.

Is this actually a problem other than your security analysis tool? The NETStandard.Library 1.6.0 package defines:

• System.Net.Http (>= 4.3.2)
• System.Text.RegularExpressions (>= 4.3.0)

Isn't NuGet downloading the newer patch versions for you anyway?

[Jevonius]

Thanks for replying - we're using Snyk for analysis, which is reporting the chain as:
Castle.Windsor@5.1.1 › Castle.Core@4.4.1 › System.Xml.XmlDocument@4.3.0 › System.Xml.ReaderWriter@4.3.0 › System.Text.RegularExpressions@4.3.0
I.e. not from the NETStandard.Library.

I'm confused about the situation for our code though - two different solutions both reference Core.4.4.1 (directly or via Windsor.5.1.1) and only one is flagging up an issue. The one that does flag only targets net472, which shouldn't be impacted if I've understood the NuGet package/DLLs correctly; the one that doesn't flag up targets both netstandard2.0 and net472 which might be confusing things. I'll keep digging!

I've been staring at screens too long. As you say, the issue only affects the .net Standard path (2.X as well 1.X) - the project flagging up the issue in our code base only targets .net Standard - elsewhere in that solution the code is .net Framework only. The solution not reporting an issue appears to be flagging a possible bug in Snyk - it's only processing the first target in the obj\project.assets.json files, rather than checking them all (both solutions should be reporting errors).

As far as I can tell, we don't see the System.Net.Http issue because it's patched during the build via the NETStandard.Library package (not sure if it would flag for a 1.3/1.5 project, we only target 2.0). Castle.Core as at 4.4.1 references System.Xml.XmlDocument.4.3.0 directly - https://github.com/castleproject/Core/blob/v4.4.1/src/Castle.Core/Castle.Core.csproj#L38 (no longer the case in the current master version so won't be an issue when v5 is released); this appears to override the reference in NETStandard.Library (at least in Snyk's world) hence being flagged up. Does the .net build process override it the other way around? I'm a little out of my depth with dependencies and build pipelines in this situation!

With regards to who should reference it manually: for any other package not auto-patched via reference in NETStandard.Library, I'd instinctively vote for it being Castle that should reference it manually, otherwise consumers doing so would have to track if the reference is still required when updating Castle.Core. In this case, I'm not sure, given my lack of knowledge around the version overrides happening in the build pipeline.

[Havunen]

Hi @jonorossi we are targeting .NET 5 and .NET 6 in our application and I would like to avoid having NETStandard.Library 1.6.0 or any of its dependencies in our application. If castle.core could add new target framework (netstandard2.0 , net5.0 , net6.0 ) or something around those lines we could get rid off these dependencies and no need to add them directly to our application

[Havunen]

These are coming from old version of .NET target framework, check my fork: https://www.nuget.org/packages/CastleCoreNet6/ it does not have these vulnerabilities. Please add modern target frameworks to castle.core

[Havunen]

#609

[IanKemp]

All of this was already resolved on 16 May 2020 by the commits made by @stakx - https://github.com/castleproject/Core/commits/master/src/Castle.Core/Castle.Core.csproj. There is no requirement for any code changes, all that is needed is to tag master at 4.5.0 or 5.0.0 and release said tag.

[jonorossi]

Closing. Please follow #613.