Microsoft To Release Emergency Fix For ASP.NET Bug

Trailrunner7 writes "Microsoft on Tuesday will release an emergency out-of-band patch for the ASP.NET padding oracle attack that was disclosed earlier this month. The patch will only be available on the company's Download Center for the time being, however. The company is taking the step of releasing an emergency fix for the bug because of the seriousness of the vulnerability — which potentially affects millions of Web applications — and the fact that there are attacks ongoing against it already. The patch will fix the flaw in all versions of the .NET framework. Although Microsoft issued guidance about workarounds to defend against attacks on the ASP.NET bug shortly after it was publicly disclosed, the researchers, Juliano Rizzo and Thai Duong, said that the workarounds did not fully protect users against their attack."

Comments

Re:How serious is this really?

[D Ninja]

First off...it's not a "decrypted cookie" - it's not that at all. The entire bug allows an attacker to download server-side information (such as web.config) which can potentially contain (and often does) information that should not be public.

Scott Guthrie wrote up a very detailed post on the vulnerability. It's fairly easy to exploit (there are videos available showing the ease in which it can be exploited), so it should be of concern to administrators and individuals writing websites/web applications running on ASP.NET.

A quick explanation

[rabtech]

First, the ViewState is encrypted so figuring out the key allows you to inject your own data into the ViewState. The worse an app's code, the worse the exploit on this because some apps even store their "IsAdmin" flag in the ViewState and other such nonsense, so this lets you impersonate any user you like. DotNetNuke is one example of a crappy system. Worse, it allows you to upload ZIP files of themes and whatnot, so you can use this to impersonate the superuser, upload some hacks, then try to execute them. Depending on what account ASP.Net runs under and whether you are fully patched, this can lead to escalation to admin and owning the box. If you have followed all the other in-depth security practices (and for coders don't store any sensitive info in the ViewState) then this isn't nearly as big of a deal.

The big hole is that starting with 3.5 SP1 (and also in 4.0) the WebResource.axd handler takes an encrypted filename as its parameter, so you can encrypt say "web.config" and get it to happily pipe web.config to you... or any other file. It completely bypasses the normal restricted file handler. In previous releases this was not the case, the stuff it would let you download was much more limited. Granted, there are facilities to encrypt connection strings/etc in web.config, but a lot of people are lazy and just deploy with plaintext passwords and whatnot. Again, following defense in-depth practices greatly restricts the scope of any potential attack.

IMHO the WebResource.axd issue is inexcusable. There is no legitimate reason for allowing the new behavior.

Re:A quick explanation

[Anonymous Coward]

Seriously? This is the second reply to this story that seems to think that it's about cookies.

Please listen carefully: this has NOTHING to do with cookies!

As the GP post and Scott Guthrie's post linked elsewhere (so helpfully) explain, this affects two encrypted elements in use by most (if not all) ASP.NET apps: the ViewState (not a cookie, rather a hidden, encrypted field for storing state across postbacks) and encrypted web.config files which tend to store sensitive connection info (among other things) that needs to be protected from attackers. The flaw allows attackers to decrypt these storage mechanisms and so get at (potentially) sensitive data, depending on how the app was coded.