https://www.youtube.com/watch?v=B2qePLeI-s8
From the HTTP must die thread a month ago. https://news.ycombinator.com/item?id=44915090
In a pure .Net world it's the norm to use strict input validation and tell clients to fix their bad requests and this looks like one of those cultural blindspots. "We" wouldn't naturally consider a case where a server accepted a request which has not been strictly validated. With the move to .Net Core and a broadening of the scope to not only target enterprises and we'll find issues like this....
Mostly this stuff comes down to skill issues.
It's really fun trying to test connectivity issues like this.
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.
You cannot do this if you're changing more than that one thing. The only way to make this work really is either dynamic environments that completely mirror everything, which tends to be time consuming or expensive or continuous delivery to a production-like environment via feature flags and so forth.
Having a staging server that is a mirror of production[1] improves things a bit over doing nothing. You need the entire environment, including all your dependencies, to have a real test of anything, and that includes things that corporate IT departments typically hate.
[1]: Why is it so common to see "PROD" written as if it were an acronym?
If you staging environment is pointing to the exact same databases PROD is, and other similar dependencies, there's no reason you can't hotswap it with PROD itself, I mean I've done something like this before.
It's much easier if your production deployment pipeline is setup for it though. You'd want to scale down drastically for staging, but in my eyes, if you're not going to have staging be as carbon copy of PROD as you humanely can have it, you might as well not have that fourth environment and just suffer when you cannot reproduce bugs. The real gem of staging is that if it would break in PROD, it would definitely break in staging. In the few companies where we had a carbon copy of PROD setup as a staging environment where key things are pulled from PROD itself, we've had way less bugs promoted to PROD when QA tests them in staging.
In theory the ROI is worth it, if you care about quality. Sadly most places do not care about quality nearly enough.
>= 6.0.0 <= 6.0.36
>= 8.0.0 <= 8.0.20
>= 9.0.0 <= 9.0.9
<= 10.0.0-rc.1
Microsoft.AspNetCore.Server.Kestrel.Core:
<= 2.3.0
I'm probably missing something, but I still don't get how this would work without a proxy unless my own code manually parses the request from scratch. Or maybe that is what the author means.
The vulnerability, as far as I understand it, relies on two components interpreting these chunks differently. So one of them has to read \r or \n as valid markers for the chunk end, and the other one must only allow \r\n as specified.
Kestrel used to allow \r and \n (and the fix is to not do that anymore). So only if my own code parses these chunks and uses \r\n would I be vulnerable, or?
The proxy version of the vulnerability seems quite clear to me, and pretty dangerous as .NET parses non-compliant and would thereby be vulnerable behind any compliant proxy (if the proxy is relevant for security aspects).
But the single application version of the vulnerability seems to me to be very unlikely and to require essentially having a separate full HTTP parser in my own application code. Am I missing something here?
r0x0r007•2h ago
CharlieDigital•2h ago
cm2187•2h ago
lsbehe•1h ago
Uvix•1h ago
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...
lsbehe•1h ago
Traubenfuchs•1h ago
Create a new project with the latest spring version, and maven will warn you.
At this point I consider this worthless noise.
weinzierl•44m ago
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.