Slashdot Mirror

← Back to Stories (view on slashdot.org)

Microsoft To Release Emergency Fix For ASP.NET Bug

Posted by Soulskill on from the don't-make-us-do-stuff dept.

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

3 of 73 comments (clear)

  1. Re:A quick explanation by ls671 · · Score: 2, Interesting

    > not a cookie, rather a hidden, encrypted field for storing state across postbacks

    Thanks a lot for the clarification, it seriously helps me understand the problem better and I really mean it.

    Now I will re-phrase my post:

    WTF ?

    Is this serious ? I thought rule 1 of using hidden form fields was to only put meaningless (OK: or already submitted data by the user) data into one. I am still having a hard time to believe this is occurring out of the box in an enterprise platform like ASP.NET.

    A hidden form field in more or less the request scoped version of a cookie, never ever store your guts into one, no matter how well it is encrypted ! ;-)

    --
    Everything I write is lies, read between the lines.
  2. Re:A quick explanation by Anonymous Coward · · Score: 1, Interesting

    Practically nothing with regards to what kind of data shouldn't be stored in either, but it pays to be precise when talking about a problem that needs fixing to ensure you're not "fixing" the wrong code.

  3. Re:A quick explanation by Anonymous Coward · · Score: 1, Interesting

    Hey, you won't find me disagreeing on your point about not storing sensitive things in cookies or ViewState and, as the OP pointed out, with proper security practices in place, this is less of an issue than having your encrypted web.config file exposed.

    As for your disbelief, I honestly can't imagine having the foresight to protect against an attack that involves:

    This allows an attacker to send cipher text to the web server and learn if it was decrypted properly by examining which error code was returned by the web server. By making many such requests (and watching what errors are returned) the attacker can learn enough to successfully decrypt the rest of the cipher text.

    and the TechNet site even mentions that an attacker can use the timing of the response to deduce the type of error (devious!) even if you use the proposed customErrors workaround.

    People make mistakes and MS is being quick about releasing the fix. Can't realistically ask for much more than that. Also, a comment above seems to indicate that this isn't restricted to ASP.NET, but can affect other frameworks that use similar mechanisms.