It sounds like this is anything built upon Kestrel which is a lot. I was going to try to list it all here, but holy cow.
ASP.NET Core:
>= 6.0.0 >= 8.0.0 >= 9.0.0 Microsoft.AspNetCore.Server.Kestrel.Core:
<= 2.3.0
Understanding the Worst .NET Vulnerability
11–20 of 67 posts
Re: Understanding the Worst .NET Vulnerability
#12That feeling when you open a brand new project in VS and immediately get: "The solution contains packages with vulnerabilities"
And now that everything is a package, it won’t get fixed with windows update. Which means that if the website isn’t actively developed and regularly deployed, it will remain vulnerable
M$ offers system wide installations. Those don't seem to be updated automatically either but at least I don't have to deploy 6 servers now.
Re: Understanding the Worst .NET Vulnerability
#13Earlier quoted context omitted.
And now that everything is a package, it won’t get fixed with windows update. Which means that if the website isn’t actively developed and regularly deployed, it will remain vulnerable
M$ offers system wide installations. Those don't seem to be updated automatically either but at least I don't have to deploy 6 servers now.
On Linux, system-wide installations are handled through the system's package manager.
On Windows, if you have the "Install updates for other Microsoft products" option enabled, .NET [Core] runtimes will be updated through Windows Update.
If the domain's group policy won't let you turn it on from the UI (or if you want to turn it on programmatically for other reasons), the PowerShell 7 installer has a PowerShell script that can be adapted to do the trick: https://github.com/PowerShell/PowerShell/blob/ba02868d0fa1d7...
Re: Understanding the Worst .NET Vulnerability
#14It sounds like this is anything built upon Kestrel which is a lot. I was going to try to list it all here, but holy cow.
ASP.NET Core: >= 6.0.0 >= 8.0.0 >= 9.0.0 Microsoft.AspNetCore.Server.Kestrel.Core: <= 2.3.0
Those are just the ones they're fixing. Versions <6.0 are still vulnerable, they're just not getting patched because they're out of support.
Re: Understanding the Worst .NET Vulnerability
#15That feeling when you open a brand new project in VS and immediately get: "The solution contains packages with vulnerabilities"
It's pretty much the same in Javaland with maven and spring.
Create a new project with the latest spring version, and maven will warn you.
At this point I consider this worthless noise.
Re: Understanding the Worst .NET Vulnerability
#16Earlier quoted context omitted.
M$ offers system wide installations. Those don't seem to be updated automatically either but at least I don't have to deploy 6 servers now.
On Linux, system-wide installations are handled through the system's package manager. On Windows, if you have the "Install updates for other Microsoft products" option enabled, .NET [Core] runtimes will be updated through Windows Update. If the domain's group policy won't let you turn it on from the UI (or if you want to turn it on programmatically for other reasons), the PowerShell 7 installer has a PowerShell scrip…
archlinux doesn't offer the new version yet. https://archlinux.org/packages/extra/x86_64/aspnet-runtime/
Only exposing stuff behind caddy so it doesn't seem to be an issue.
Re: Understanding the Worst .NET Vulnerability
#17Earlier quoted context omitted.
ASP.NET Core: >= 6.0.0 >= 8.0.0 >= 9.0.0 Microsoft.AspNetCore.Server.Kestrel.Core: <= 2.3.0
Those are just the ones they're fixing . Versions <6.0 are still vulnerable, they're just not getting patched because they're out of support.
Don't use out of support software or at least don't use out of support software exposed to the internet.
Re: Understanding the Worst .NET Vulnerability
#18It has been in the making for at least ten years, the problem for me has been that that production environments and test environments are not the same when you use proxys. So you need to check both, and you need to have the same type of connection that your customers use. https://www.youtube.com/watch?v=B2qePLeI-s8 From the HTTP must die thread a month ago. https://news.ycombinator.com/item?id=44915090
This tends to be huge in enterprise. Development, test/UAT, and production will all have different proxy methods and requirements. Devs may have a proxy with NTLM. Test may have something like proxy auto detect. Prod may be manually defined.
It's really fun trying to test connectivity issues like this.
Re: Understanding the Worst .NET Vulnerability
#19That feeling when you open a brand new project in VS and immediately get: "The solution contains packages with vulnerabilities"
It's pretty much the same in Javaland with maven and spring. Create a new project with the latest spring version, and maven will warn you. At this point I consider this worthless noise.
I think Spring doesn't consider vulnerabilities in one of their components to be a Spring vulnerability. At least they do not release an updated version until the next scheduled patch version, not even in the paid version.
You can either wait and accept being vulnerable or update the component yourself and therefore run an unsupported and untested configuration. Doomed if you do, doomed if you don't.
Re: Understanding the Worst .NET Vulnerability
#20It has been in the making for at least ten years, the problem for me has been that that production environments and test environments are not the same when you use proxys. So you need to check both, and you need to have the same type of connection that your customers use. https://www.youtube.com/watch?v=B2qePLeI-s8 From the HTTP must die thread a month ago. https://news.ycombinator.com/item?id=44915090
This tends to be huge in enterprise. Development, test/UAT, and production will all have different proxy methods and requirements. Devs may have a proxy with NTLM. Test may have something like proxy auto detect. Prod may be manually defined. It's really fun trying to test connectivity issues like this.
In a high quality setup you have a staging server that is a carbon copy of PROD. Bonus points if you make it so staging and PROD are 100% interchangeable, to the level that you can point PROD to staging, and then turn PROD into staging, and do the same next deployment. If you can do that, you have a stronger change of at least reproducing production issues.
Dev, UAT / QA, Staging, PROD. This is the ideal setup in my eyes. It lets QA / UAT hold changes that are maybe not 100% ready, while not blocking testing that is mean to go into PROD ASAP because it can sit in staging.