3 ms·

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

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.

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.