4 ms·

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 chec

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.stream.copyto?view=net-9.0 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.)

cimtiaz 1y ago
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.
WorldMaker 1y ago
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.
- fabian2k 1y ago
  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.
  - WorldMaker 1y ago
    "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.
immibis 1y ago
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.
- gwbas1c 1y ago
  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.

cimtiaz 1y ago

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.

WorldMaker 1y ago

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.

fabian2k 1y ago
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.
- WorldMaker 1y ago
  "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.

immibis 1y ago

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.

gwbas1c 1y ago
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.