> And as a final reminder, even though request smuggling is typically described and demonstrated using a proxy in front of your server, just not using a proxy does not mean you're automatically safe. If you're reading, manipulating, or forwarding request streams directly in ASP.NET Core, as opposed to just relying on the built-in model binding, then you might be at risk to request smuggling attacks.
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?
Basically, if you handle the request at the stream level, there's a small chance you might be vulnerable.
For example, let's say you have an HTTP API that checks a few headers and then makes another outgoing HTTP request. You might just send the stream along, using incomingHttpRequestStream.CopyTo(outgoingHttpRequestStream) / (or CopyToAsync). (https://learn.microsoft.com/en-us/dotnet/api/system.io.strea...)
That might be vulnerable, because it could trick your server to send what appears to be two HTTP requests, where the 2nd one is whatever the malicious party wants it to be... But only if you allow incoming HTTP versions < 2. If you blanket disallow HTTP below 2.0, you aren't vulnerable.
---
But I agree that this seems to be more "much ado about nothing" and doesn't deserve 9.9:
> In the python aiohttp and ruby puma servers, for example, give the vulnerability only a moderate severity rating in both cases. In netty it's even given a low severity.
I suspect the easiest way to handle this is to disallow HTTP < 2 and then update .Net on your own schedule. (Every minor release of .Net seemed to break something at my company, so we had to lock down to the patch otherwise our build was breaking every 2-3 months.)
There's actually a near 100% chance you're vulnerable if you handle HTTP - or any other non-binary protocol allowing connection reuse - at the stream level, and don't parse strictly (close connection on duplicate content-length, on chunked encoding with content-length, on duplicate transfer-encoding, on bare CR or LF, etc).
If you blanket disallow old HTTP, clients will fail to reach you.
No, it's only if you forward the body to another HTTP request. If you're deserializing to an object, you are not vulnerable.
Blanket disallowing old HTTP depends on who is calling your web service: I don't think modern browsers need to fall back to HTTP v1; so the risk is if you have a web service that is called by scripts or other programs using old HTTP libraries.
Even then, it's pretty well established that no one remains compatible with old TLS libraries, so I don't see why we need to remain compatible with old HTTP libraries indefinitely.
I also agree, it should be patched anyway, but the 9.9 score is somewhat misleading here ..... I think Microsoft is scoring the theoretical maximum impact across all possible ASP.NET Core applications, not the vulnerability in isolation. Most production deployments behind modern proxies like nginx, Cloudflare, AWS ALB etc., are likely already protected. Because these proxies reject the malformed chunked encoding that Kestrel was incorrectly accepting. The real risk is for apps directly exposing Kestrel to the internet or using older or misconfigured proxies.
I think the big reason this escalates to such a high score is because the Middleware abstraction common in a lot of HTTP server designs today (including Kestrel, ASP.NET being sometimes viewed in its modern implementation as entirely a stack of Middleware in a single trenchcoat) can also be a series of nesting doll "micro-proxies" manipulating the HTTP request in various ways before passing it to code that trusts the Middleware did its job. With Middleware doing all sorts of jobs but especially various steps of Authentication and Authorization, there can be a lot of security risks if there were vulnerable middleware.
It wouldn't surprise me if Microsoft found a first-party or second-party (support contract) or open source/nuget Kestrel/ASP.NET Middleware somewhere in the wild that was affected by this vulnerability in a concerning way. In that case, it also somewhat makes sense that Microsoft doesn't necessarily want to victim blame the affected Middleware given that they recognized that Kestrel itself should have better handled the vulnerability before it ever passed to Middleware.
But the middleware would usually not work on the raw http request, but the version already parsed by Kestrel. So everything should see the same version of the request, the one with the non-spec-compliant parsing by Kestrel.
"Usually", sure, but there's also nothing stopping a Middleware from doing whatever it likes with the raw HTTP request. A streaming large file upload middleware, for instance, might have reason to work more directly with Transfer-Encoding: Chunked to optimize its own processes, using a custom "BodyReader".
The CVE points out (and the article as well) some issue with user-land code using `HttpRequest.BodyReader` on the "parsed" request, it just doesn't include specifics of who was using it to do what. Plenty of Middleware may have reason to do custom BodyReader parsing, especially if it applies ahead of ASP.NET Model Binding.
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?