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

31–40 of 67 posts

Re: Understanding the Worst .NET Vulnerability

#31

Post by gwbas1c »

fabian2k wrote: post #9

> 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 miss…

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 ---

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.)

Re: Understanding the Worst .NET Vulnerability

#32

Post by pixl97 »

ozim wrote: post #17
Uvix wrote: post #14

Earlier quoted context omitted.

Those are just the ones they're fixing . Versions <6.0 are still vulnerable, they're just not getting patched because they're out of support.

Don't use out of support software or at least don't use out of support software exposed to the internet.

Internal attacks are easy enough in a large enough network.

Re: Understanding the Worst .NET Vulnerability

#33

Post by klysm »

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.

Re: Understanding the Worst .NET Vulnerability

#34

Post by haydenbarnes »

nirvana99 wrote: post #11
forksspoons wrote: post #6

It sounds like this is anything built upon Kestrel which is a lot. I was going to try to list it all here, but holy cow.

ASP.NET Core: >= 6.0.0 >= 8.0.0 >= 9.0.0 Microsoft.AspNetCore.Server.Kestrel.Core: <= 2.3.0

>= 6.0.0 Fixes are available for .NET 6 from HeroDevs ongoing security support for .NET 6, called NES* for .NET.

*never ending support

Re: Understanding the Worst .NET Vulnerability

#35

Post by motorest »

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.

> Being liberal in what you accept comes at _huge_ costs to the entire ecosyste

Why do you believe that?

Being liberal in what you accept doesn't mean you can't do input validation or you're forced to pass through unsupported parameters.

It's pretty obvious you validate the input that is relevant to your own case, you do not throw errors if you stumble upon input parameters you don't support, and then you ignore the irrelevant fields.

The law is "be conservative in what you send, be liberal in what you accept". The first one is pretty obvious.

How do you add cost to the entire ecosystem by only using the fields you need to use?

Re: Understanding the Worst .NET Vulnerability

#36

Post by voxic11 »

cm2187 wrote: post #10
r0x0r007 wrote: post #2

That feeling when you open a brand new project in VS and immediately get: "The solution contains packages with vulnerabilities"

And now that everything is a package, it won’t get fixed with windows update. Which means that if the website isn’t actively developed and regularly deployed, it will remain vulnerable

Actually this bug is in Microsoft.AspNetCore.App.Runtime which is an implict package that comes from the runtime. So simply updating your version of the dotnet should fix any vulnerable applications.

Re: Understanding the Worst .NET Vulnerability

#37

Post by pixl97 »

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…

>In a high quality setup you have a staging server that is a carbon copy of PROD

In low throughput environments I see stuff like this. The problem is with high throughput environments it doesn't tend to happen because of the massive expense incurred.

Re: Understanding the Worst .NET Vulnerability

#38

Post by throwaway201606 »

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…

There are many setups where this is not just not possible. In some cases, doing this is prohibitive because of cost or prohibited by law.

+ for case of cost: lots of very large companies have prod environments that cost big $$$. Business will not double prod cost for a staging environment mirroring prod. Take an example of any large bank you know. The online banking platform will cost tens if not hundreds of millions of dollars to run. Now consider that the bank will have hundreds of different platforms. It is just not economically feasible.

+ for the case of law: in some sectors, by law, only workers with "need to know" can access data. Any dev environment data cannot, by law, be a copy of prod. It has to be test data, even anonymization prod data is not allowed in dev/test because of de-anonymization risk.

Given this, consider a platform / app that is multi-tenant (and therefore data driven ) eg a SaaS app in a legally regulated industry such as banking or health care. Or even something like Shopify or GMail for corporate where the app hosts multiple organizations and the org to be used is picked based on data (user login credentials).

The app in this scenario is driven by data parameterization - the client site and content are data driven e.g. when clientXYZ logs on, the site becomes https://clientXYZ.yourAppName.com and all data, config etc are "clientXYZ" specific. And you have hundreds or thousands of clentsAAA through clientZZZ on this platform.

In such a world, dev & test environments can never be matched with prod. Further, the behaviour of the client specific sites could be different even with the same code because data parameters drive app behaviour.

Long story short, mirroring staging and prod is just not feasible in large corporate tech

Re: Understanding the Worst .NET Vulnerability

#39

Post by throwaway201606 »

pixl97 wrote: post #37
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…

>In a high quality setup you have a staging server that is a carbon copy of PROD In low throughput environments I see stuff like this. The problem is with high throughput environments it doesn't tend to happen because of the massive expense incurred.

just saw your answer - we are thinking exactly the same thing but I took the long-winded route to saying it

Re: Understanding the Worst .NET Vulnerability

#40

Post by cimtiaz »

gwbas1c wrote: post #31
fabian2k wrote: post #9

> 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 miss…

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 m…

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.
Post reply on HN