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

ASP.NET Security Feature Bypass Vulnerability

nvd.nist.gov

Post reply on HN
Print view View original

51–57 of 57 posts

Re: ASP.NET Security Feature Bypass Vulnerability

#51

Post by whizzter »

BartjeD wrote: post #8

Interesting that they put it as 'Less likely to be exploited' but at the same time give it a 9.9 riskiness. It sort of implies it will be quikcly under active investigation by hostile actors, and then get's raised to an urgent threat?

The GH issue mentions POTENTIAL risks, looked at the patch and I can see 2 scenarios:

1: You have a load-balancer infront that handles authentication somehow and then coalesces multiple incoming requests into single connections, one authenticated user's request can then somehow to be confused by the backend to the attackers that can then impersonate.

2: The .NET request pipeline seems to be meant to be fairly thin to enable performance, potentially you have some middleware for authentication that again gets fooled by this bug.

I think the high rating is that if it is found out that some popular application like Umbraco turns out to be vulnerable, then tons of targets will be viable and having them patch their servers before that is found out is beneficial.

Re: ASP.NET Security Feature Bypass Vulnerability

#52

Post by whizzter »

yread wrote: post #32

Isn't this only exploitable if you expose Kestrel to the internet? They (used to?) recommend to put a proxy in front of it so I would guess most deployments are done like that

Actually, I think that a proxy might be a worse scenario in terms of exploitability.

If the proxy that handles authentication has one notion of chunked encoding and Kestrel behind it has another notion and the proxy then shares it's connection between users, then an attacker might smuggle in a request to a high value endpoint.

For example:

- Kestrel serves an application with the endpoints /public_get_stats and /admin/change_user_rights

- The proxy makes sure everything under /admin is authorized

- An attacker does a POST request to /public_get_stats , the post is sent with CHUNKED encoding that the proxy interprets in one way thus letting it be passed to Kestrel

- Kestrel behind it starts processing /public_get_stats but mis-interprets the chunked boundary leaving the parser to start the next (malicious) request, that in turn contains, a payload saying {"userid":"hacker","level":"superuser"} to /admin/change_user_rights

Re: ASP.NET Security Feature Bypass Vulnerability

#53

Post by bob1029 »

Hawxy wrote: post #17
zovin wrote: post #10

For context around the score https://github.com/dotnet/aspnetcore/issues/64033#issuecomme...

This appears to be the code change: https://github.com/dotnet/aspnetcore/commit/97a86434195a82fc...

Looks like a line ending problem. RejectsInvalidChunkExtensions seems to be the unit test that covers the actual concern.

Re: ASP.NET Security Feature Bypass Vulnerability

#55

Post by daveoc64 »

sofixa wrote: post #43
bob1029 wrote: post #11

> If you are running .NET 8 or later install the .NET update from Microsoft Update, then restart your application or reboot the machine. This is why I advocate for .NET in serious business contexts. You often don't have to rebuild or redeploy your software if you are using the included batteries as intended. A devops intern could handle this fix. Contrast with virtually any other ecosystem.

> You often don't have to rebuild or redeploy your software if you are using the included batteries as intended Instead, your software's lifecycle is entirely dependent on the OS' lifecycle. That seems worse. And for what it's worth, it would be exactly the same with any "interpreted"/VM-based language - Java and family friends, Python, Ruby, etc. Just update the VM/interpreter and restart (the service though, not th…

>Instead, your software's lifecycle is entirely dependent on the OS' lifecycle. That seems worse.

It's not.

.NET updates are shipped with Windows Update, but can be installed separately.

Obviously for macOS and Linux you can't get them through Windows Update anyway.

Re: ASP.NET Security Feature Bypass Vulnerability

#56

Post by orphea »

pverheggen wrote: post #40
pjmlp wrote: post #36

Earlier quoted context omitted.

Yes, there is, because Microsoft naming sucks, and making the distiction between .NET Core and .NET Framework is the only way to actually explain modern .NET to most folks without background on .NET. Additionally the mistake to rename .NET Core as .NET is the main reason many people still think .NET is Windows only.

Well they did have a valid reason for a rename, .NET 5.0's announcement coincided with discontinuing Mono and Xamarin, and uniting the non-Windows .NET flavors under a single platform. They also planned to iterate more rapidly and add APIs beyond .NET Standard. But yes, choosing ".NET" as the new name was a bad idea, since now when someone says .NET you have no idea if they are referring to the modern runtime, or its…

I, for one, think dropping the "Core" suffix (absolutely dumb naming) was the right thing. Yes, it might have created some confusion with the old .NET aka .NET Framework but I hope it's temporary. It's been five years of .NET-no-suffix and nine of it being cross-platform. At some point people should just educate themselves and stop thinking that .NET is somehow Windows only.

Re: ASP.NET Security Feature Bypass Vulnerability

#57

Post by pjmlp »

orphea wrote: post #56
pverheggen wrote: post #40

Earlier quoted context omitted.

Well they did have a valid reason for a rename, .NET 5.0's announcement coincided with discontinuing Mono and Xamarin, and uniting the non-Windows .NET flavors under a single platform. They also planned to iterate more rapidly and add APIs beyond .NET Standard. But yes, choosing ".NET" as the new name was a bad idea, since now when someone says .NET you have no idea if they are referring to the modern runtime, or its…

I, for one, think dropping the "Core" suffix (absolutely dumb naming) was the right thing. Yes, it might have created some confusion with the old .NET aka .NET Framework but I hope it's temporary. It's been five years of .NET-no-suffix and nine of it being cross-platform. At some point people should just educate themselves and stop thinking that .NET is somehow Windows only.

Good luck with that, the .NET team keeps referring this is a recurring problem trying to get new users that rather pick something else for their startups or teaching curriculum, just go listen to .NET podcasts where well known figures got interviewed.
Post reply on HN