back to article MS emergency fix plugs ASP.Net web development hole

Microsoft has released an out-of-cycle patch designed to address a serious flaw in its ASP.Net web application development toolkit. The vulnerability, which has been under active attack for several weeks, creates a mechanism for attackers to read any file on a web application server. Microsoft rates the flaw as only "important …


This topic is closed for new posts.
  1. Anonymous Coward

    Testimonial For Open Source

    It took MS weeks to provide a fix which would have taken two days in the OS community. Meanwhile the miscreants messed with other people's data on unprotected servers, as everybody could read about the exploit weeks ago.

    Also, MS apparently has zero security competence, assessing all their cock-ups. One of the best was using RC4 to encipher Word documents without using different IVs. Now we all know what Bill Gates meant with "Security Development Lifecycle".


    1. Chris Harden
      Gates Halo

      How long it takes Microsoft to change on line of code

      Hanselman tweeted a great article a while back (which I can no longer find, sorry - if anyone knows it please send it on, it was a great article) which demonstrated how long it takes Microsoft to change one line of code.

      The reason they take so long is because one change affects thousands of developers, who's code then affects thousands more end users, so the QA has to be rediculously high, including regression testing to make sure a patch will not somehow break someone else's codebase.

      Then, after this the process has to go through localization which again, includes testing but this time in dozens more frameworks which are localized.

      Ten days ain't bad considering the standards to which MS adhere to.

      I know I sound like a MS whore (ok, I'm a C# Developer so I AM a MS whore) but credit where credit is due.

      1. Anonymous Coward

        Are you really a programmer?

        "The reason they take so long is because one change affects thousands of developers, who's code then affects thousands more end users, so the QA has to be rediculously high, including regression testing to make sure a patch will not somehow break someone else's codebase."

        Handling changes is not new. Especially for the open source world. I get updates daily. Never had an update mess something up. Which is incredible considering all those 10 thousands of developers changing a lot of lines of code.

        As a programmer you must have heard about modular system design, interfaces and that kind of stuff. That makes it possible to change code without affecting the work of other people.

        I really want to read that article now. How is it possible, if you design software the right way, that a single line of code can affect 10*10^4 other developers? Surely Microsoft must have some design goals, preventing this scenario.

        I understand that there are QA procedures, but this is a bit far fetched.

      2. Anonymous Coward

        Every heard of Hotfixes ?

        What they could do is to push out a hotfix two days after recognizing a problem and skip extensive testing for that. Users would make the deployment/non-deployment decision themselves.

        Competent users have a sandbox where they can test a patch without affecting production.

        Two weeks later the "highly tested/officially sanctioned" version of the patch would be distributed as an automatic update.

  2. Chris Harden

    El Reg - Please please do find out what they patched

    The bigger issue here is that ScriptResource.axd can read ANY file from the file system (it's like a SQL injection on crack), as this is a patch I can't find out from the .NET source code, and Microsoft are being quite silent on the issue - could you find out please whether this fix is just to the encryption weakness or if it closes the rather rediculous ability for ScriptResource to pull any file it chooses off of the file system.

    There is a pint in it for ya,



    1. Martin Marv

      Why not download the patch to find out?

      Use Reflector to check the current code, download the patch and compare.

      If it's still an issue, then put your own wrapper around the ScriptResource functionality that will only return specific file-types...

      1. Chris Harden


        Don't need it for the base Framework, but of course, I could reflect the patch - thanks man good call.

        I slapped an semi-patch idea over here: - I'd prefer just to shut down the feature that allows it to read the file system completely.

        To be hoenst though, it would just be better if MS fixed the issue themselves, save hacking something over the top of it.

  3. MaaWaa


    ok, im fairly sure this issue was made public at a blackhat security conference (without informing microsoft) on Fri 17th, work arounds and alternative protection was provided by MS on 20th and a full patch by the 28th,

    i think they handled it superbly for once

  4. Neal 5


    Head/Arse is all.

    1. Anonymous Coward

      What A Qualified Response

      I know that quite a few careers depend on MS, so I should expect some flaming. Still, Adobe, MS and Oracle display a truely soviet-style-bureaucratic behaviour when it comes to patching. And their developers are badly trained in security subjects.

      I would expect every MS developer attend a two-week seminar on crypto and security subjects. They should know what a symmetric cipher, a public-key cipher, a strong hash, buffer overflows, SQL injections, message authentication, security/lackof of stream ciphers, weak random numbers& session hijacking are. Apparently other stuff is more important to MS management. Like pushing out new features which will drive sales ($$$!) as quickly as possible.

      Most developers are lazy bastards who don't educate themselves. So management has to drag them into trainings. Apparently MS doesn't manage. Linux and BSD do. Without centralized management.

  5. Anonymous Hero

    Nothing to do with .NET's cryptographic strength...

    "The vulnerability stems from a cryptographic weakness, specifically involving improper error handling during encryption padding verification.".

    I wish the IT press would get it's facts straight instead of bandying around sensationalist crap like this .

    This has nothing to do with a cryptographic weakness, this is about ASP.NET revealing too much useful information when a CryptographicException is thrown.

This topic is closed for new posts.