6 ms·
Understanding the Worst .NET Vulnerability
- r0x0r007 1y agoThat feeling when you open a brand new project in VS and immediately get: "The solution contains packages with vulnerabilities"
- CharlieDigital 1y agoThat's a Good Thing rather than shipping vulnerable code.
- cm2187 1y agoAnd 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
- lsbehe 1y agoM$ offers system wide installations. Those don't seem to be updated automatically either but at least I don't have to deploy 6 servers now.
- Uvix 1y agoOn Linux, system-wide installations are handled through the system's package manager. On Windows, if you have the "Install updates for other Microsoft products" option enabled, .NET [Core] runtimes will be updated through Windows Update. If the domain's group policy won't let you turn it on from the UI (or if you want to turn it on programmatically for other reasons), the PowerShell 7 installer has a PowerShell script that can be adapted to do the trick: https://github.com/PowerShell/PowerShell/blob/ba02868d0fa1d724fcde39e612534d3db693eb39/assets/MicrosoftUpdate/RegisterMicrosoftUpdate.ps1 https://github.com/PowerShell/PowerShell/blob/ba02868d0fa1d7...
- lsbehe 1y agoarchlinux doesn't offer the new version yet. https://archlinux.org/packages/extra/x86_64/aspnet-runtime/ https://archlinux.org/packages/extra/x86_64/aspnet-runtime/ Only exposing stuff behind caddy so it doesn't seem to be an issue.
- voxic11 1y agoActually 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.
- Traubenfuchs 1y agoIt's pretty much the same in Javaland with maven and spring. Create a new project with the latest spring version, and maven will warn you. At this point I consider this worthless noise.
- weinzierl 1y agoI think Spring doesn't consider vulnerabilities in one of their components to be a Spring vulnerability. At least they do not release an updated version until the next scheduled patch version, not even in the paid version. You can either wait and accept being vulnerable or update the component yourself and therefore run an unsupported and untested configuration. Doomed if you do, doomed if you don't.
- deleted 1y ago[deleted]
- pastage 1y agoIt has been in the making for at least ten years, the problem for me has been that that production environments and test environments are not the same when you use proxys. So you need to check both, and you need to have the same type of connection that your customers use. https://www.youtube.com/watch?v=B2qePLeI-s8 https://www.youtube.com/watch?v=B2qePLeI-s8 From the HTTP must die thread a month ago. https://news.ycombinator.com/item?id=44915090 https://news.ycombinator.com/item?id=44915090
- radicalbyte 1y agoThe 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 case where a server accepted a request which has not been strictly validated. With the move to .Net Core and a broadening of the scope to not only target enterprises and we'll find issues like this....
- jen20 1y agoI 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.
- PantaloonFlames 1y agoIf I transmit SOAP or JSONRPC over http, both of which use the response payload itself to contain whether the request was an error or not, what should the status be in case of error ? I jsonrpc I think 200 OK is correct with an error payload that says “you are not authorized” or similar.
- 1y ago
- forksspoons 1y agoIt 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.
- nirvana99 1y agoASP.NET Core: >= 6.0.0 <= 6.0.36 >= 8.0.0 <= 8.0.20 >= 9.0.0 <= 9.0.9 <= 10.0.0-rc.1 Microsoft.AspNetCore.Server.Kestrel.Core: <= 2.3.0
- Uvix 1y agoThose 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.
- haydenbarnes 1y ago>= 6.0.0 <= 6.0.36 versions are not being fixed by Microsoft. Fixes are available for .NET 6 from HeroDevs ongoing security support for .NET 6, called NES* for .NET. *never ending support
- Bluescreenbuddy 1y ago7 is also EOL. It did not receive a patch. Last time it was updated was May 2024
- rana762 1y ago[dead]
- fabian2k 1y ago> 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 missing something, but I still don't get how this would work without a proxy unless my own code manually parses the request from scratch. Or maybe that is what the author means. The vulnerability, as far as I understand it, relies on two components interpreting these chunks differently. So one of them has to read \r or \n as valid markers for the chunk end, and the other one must only allow \r\n as specified. Kestrel used to allow \r and \n (and the fix is to not do that anymore). So only if my own code parses these chunks and uses \r\n would I be vulnerable, or? The proxy version of the vulnerability seems quite clear to me, and pretty dangerous as .NET parses non-compliant and would thereby be vulnerable behind any compliant proxy (if the proxy is relevant for security aspects). But the single application version of the vulnerability seems to me to be very unlikely and to require essentially having a separate full HTTP parser in my own application code. Am I missing something here?
- gwbas1c 1y agoBasically, 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.)
- froggertoaster 1y agoI'm a simple man. I see Andrew Lock, I upvote.
- mzs 1y agohttps://w4ke.info/2025/06/18/funky-chunks.html https://w4ke.info/2025/06/18/funky-chunks.html
- colseph 1y agoI wonder how many vulnerabilities have been accidentally created by adherence to postel's law rather than just being strict in what's accepted too.
- capitol_ 1y agoIf "A billion dollar mistake" wasn't already taken by 'null', then this would be a good candidate.
- ahoka 1y agoOh null is fine, but "everything is nullable" is the devil.
- klysm 1y agoI 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.
- motorest 1y ago> 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?
- SAI_Peregrinus 1y agoThe 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 change. I like to call it the "hardness principle". It makes your system take longer to break, but when it does it's more damaging than it would have been if you'd rejected malformed input in the first place.
- kikimora 1y agoIsn’t the problem comes down to proxy not rejecting a request with two Content-Length headers? If proxy and upstream parse HTTP correctly they would either won’t touch data past the Content-Length or they would never see two HTTP requests even if content is chunked and contain bytes similar to a HTTP request.
- throw7 1y agoMany moons ago, we used to run a full application level http proxy firewall. It didn't last the year. False positives were a headache and sites would just send shit down the pipe and browsers would happily power through. I don't hate postel's law, but I admit I try not to think about it lest I get triggered by a phone call that such and such site doesn't work.
- marcosdumay 1y agoFalse positives on snake-oil security software have no relation at all with Postel's law.
- cimtiaz 1y agoOn 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.