Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding the Worst .NET Vulnerability

andrewlock.net

Post reply on HN
Print view View original

51–60 of 67 posts

Re: Understanding the Worst .NET Vulnerability

#51

Post by robertlagrant »

motorest wrote: post #47
SAI_Peregrinus wrote: post #42

Earlier quoted context omitted.

The problem with Postel's law is that people apply it to interpreting Postel's law. They read it as encouraging you to accept any input, and trying to continue in the face of nonsense. They accept malformed input & attempt to make sense of it, instead of rejecting it because the fields they care about are malformed. Then the users depend on that behavior, and it ossifies. The system becomes brittle & difficult to cha…

> They accept malformed input & attempt to make sense of it, instead of rejecting it because the fields they care about are malformed. I don't think that's true at all. The whole point of the law is that your interfaces should be robust, and still accept input that might be nonconforming in some way but still be possible to validate. The principle still states that if you cannot validate input, you should not accept…

The state of HTML parsing should convince you that if you follow postel's law in one browser then every other browser has to follow it in the same way.

Re: Understanding the Worst .NET Vulnerability

#52

Post by jon-wood »

giancarlostoro wrote: post #20
pixl97 wrote: post #18

Earlier quoted context omitted.

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…

Today in petty off-topic complaints I expect to burn some karma on: PROD isn't capitalised, is an abbreviation of Production, not an initialism of Public Ready Outside-world Delivery.

Re: Understanding the Worst .NET Vulnerability

#53

Post by cimtiaz »

On a related note, I would recommend readers using the affected .NET 8/9 runtime in containerized applications to consider rebuilding their container images using the patched base images and redeploy them. Unlike Azure App Service, the .NET runtime is embedded within container images and is not automatically patched by Microsoft's platform updates. It has to be rebuild and redeploy to receive security fixes.

Re: Understanding the Worst .NET Vulnerability

#54

Post by wvenable »

klysm wrote: post #33
colseph wrote: post #25

I wonder how many vulnerabilities have been accidentally created by adherence to postel's law rather than just being strict in what's accepted too.

I frequently get into this argument with people about how Postel's law is misguided. Being liberal in what you accept comes at _huge_ costs to the entire ecosystem and there are much better ways to design flexibility into protocols.

My counter argument is that the entire web exists because of Postel's law. HTML would just be another obsolete boring document format from the 1980s.

I agree that there are better ways to design flexibility into protocols but that requires effort, forethought, and most of all imagination. You might not imagine that your little scientific document format would eventually become the world's largest application platform and plan accordingly.

Re: Understanding the Worst .NET Vulnerability

#55

Post by drysart »

robertlagrant wrote: post #51
motorest wrote: post #47

Earlier quoted context omitted.

> They accept malformed input & attempt to make sense of it, instead of rejecting it because the fields they care about are malformed. I don't think that's true at all. The whole point of the law is that your interfaces should be robust, and still accept input that might be nonconforming in some way but still be possible to validate. The principle still states that if you cannot validate input, you should not accept…

The state of HTML parsing should convince you that if you follow postel's law in one browser then every other browser has to follow it in the same way.

That's a truism in general. If you're liberal in what you accept, then the allowances you make effectively become part of your protocol specification; and if you hope for interoperability, then everyone has to be follow the same protocol specification which now has to include all of those unofficial allowances you (and other implementors) have paved the road to hell with. If that's not the case, then you don't really have compatible services, you just have services that coincidentally happen to work the same way sometimes, and fail other times in possibly spectacular ways.

I have always been a proponent for the exact opposite of Postel's law: If it's important for a service to be accommodating in what it accepts, then those accommodations should be explicit in the written spec. Services MUST NOT be liberal in what they accept; they should start from the position of accepting nothing at all, and then only begrudgingly accept inputs the spec tells them they have to, and never more than that.

HTML eventually found its way there after wandering blindly in the wilderness for a decade and dragging all of us behind it kicking and screaming the entire time; but at least it got there in the end.

Re: Understanding the Worst .NET Vulnerability

#56

Post by WorldMaker »

fabian2k wrote: post #49
WorldMaker wrote: post #43

Earlier quoted context omitted.

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…

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.

Re: Understanding the Worst .NET Vulnerability

#57

Post by drysart »

jon-wood wrote: post #52
giancarlostoro wrote: post #20

Earlier quoted context omitted.

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…

Today in petty off-topic complaints I expect to burn some karma on: PROD isn't capitalised, is an abbreviation of Production, not an initialism of Public Ready Outside-world Delivery.

PROD isn't capitalized because it's an initialism. It's capitalized because the machine is screaming at you that this is production, be careful. ;)

Re: Understanding the Worst .NET Vulnerability

#58

Post by marcosdumay »

klysm wrote: post #33
colseph wrote: post #25

I wonder how many vulnerabilities have been accidentally created by adherence to postel's law rather than just being strict in what's accepted too.

I frequently get into this argument with people about how Postel's law is misguided. Being liberal in what you accept comes at _huge_ costs to the entire ecosystem and there are much better ways to design flexibility into protocols.

There are different interpretations about what "being liberal" means.

For example, some JSON parsers extend the language to accept comments and trailing commas. That is not a change that creates vulnerability.

Other parsers extend the language by accepting duplicated keys and disambiguate them with some random rule. That is is a vulnerability factory.

Being flexible by creating a well defined superlanguage is completely different from doing it with an ill-defined one that depends on heuristics and implementation details to be evaluated.

Re: Understanding the Worst .NET Vulnerability

#59

Post by motorest »

robertlagrant wrote: post #51
motorest wrote: post #47

Earlier quoted context omitted.

> They accept malformed input & attempt to make sense of it, instead of rejecting it because the fields they care about are malformed. I don't think that's true at all. The whole point of the law is that your interfaces should be robust, and still accept input that might be nonconforming in some way but still be possible to validate. The principle still states that if you cannot validate input, you should not accept…

The state of HTML parsing should convince you that if you follow postel's law in one browser then every other browser has to follow it in the same way.

> The state of HTML parsing should convince you that if you follow postel's law in one browser then every other browser has to follow it in the same way.

No. Your claim expresses a critical misunderstanding of the principle. It's desirable that a browser should be robust to support broken but still perfectly parceable HTML. Otherwise, it fails to be even useable when dealing with anything but perfectly compliant documents, which mind you means absolutely none whatsoever.

But just because a browser supports broken documents, that doesn't make them less broken. It just means that the severity of the issue is downgraded, and users of said browser have one less reason to migrate.

Re: Understanding the Worst .NET Vulnerability

#60

Post by j_w »

jen20 wrote: post #21
radicalbyte wrote: post #8

Earlier quoted context omitted.

The problem is that we have a culture of accepting mangled requests on the web. This happens in application code too - because web developers are sloppy it's common to either disable or not use strict input validation. 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 cas…

I don't know about "not targeting enterprise" being the problem here - it's super common to find "enterprise" .NET APIs that return 200 for every possible condition and put some error text as a JSON blob in the response with "success" = "false" while setting caching headers. Mostly this stuff comes down to skill issues.

At one point I interacted with an API that would return 200 for every condition, but with a "status" field that would have "OK" or "error", except on some browsers where it would use "OKAY" instead of "OK".
Post reply on HN