Microsoft's incredible IE patch turnaround

Microsoft's incredible IE patch turnaround

Summary: Guest post by Eric SchultzeMicrosoft's latest Internet Explorer out-of-band patch release needs to be installed right away.  The number of infected websites is growing at an alarming rate -- even people visiting legitimate websites are getting hacked with this exploit.

SHARE:
44

Guest post by Eric Schultze

Apply IE emergency update now, donÂ’t ask questions — Eric SchultzeMicrosoft's latest Internet Explorer out-of-band patch release needs to be installed right away.  The number of infected websites is growing at an alarming rate -- even people visiting legitimate websites are getting hacked with this exploit.

Patch it now - just do it.  Why did this come out as an emergency release?

[ SEE: As attacks escalate, MS readies emergency IE patch ]

It  looks like Microsoft was informed of the IE zero day at the same time as everyone else – namely, last Tuesday (Patch Tuesday).  Based on Microsoft MSRC blog posts, starting on Tuesday, Microsoft studied the exploit and reviewed source code and determined that it impacted all versions of IE.   From that point on, it can be assumed that Microsoft has been working quickly on a patch for all versions of IE.

Microsoft had to determine how serious the issue was – as that gave them guidance as to whether or not to release an out of band patch or wait until the next monthly cycle.  By late last week, Microsoft was aware that this issue was starting to infect user’s systems at a faster rate than they’ve seen with past zero day exploits.  Specifically, attackers were loading the exploit on legitimate websites so that even users who visit only non-nefarious websites might also get infected.  Based on this level of data, it’s my belief that Microsoft decided the issue warranted an out-of-band patch release.

[ SEE: Hackers exploiting (unpatched) IE 7 flaw to launch drive-by attacks ]

Researching, fixing, testing, and releasing a security patch within an eight day window is an incredible feat -- especially given the need to support all versions of IE across all platforms and languages.  This is an ‘all hands on deck’ response from Microsoft – I don’t think we’ll see this as the norm for less critical patches in the future as it is quite disruptive to their own processes.

Now, it’s equally as important for customers to roll out this patch to all of their systems as soon as possible.

I’d bet you a cookie that many companies can’t get it rolled out as quickly as Microsoft got it built.

* Eric Schultze is chief technology officer at Shavlik Technologies, a vulnerability management company.

Topics: Browser, Microsoft, Security

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

44 comments
Log in or register to join the discussion
  • So much for the "sitting on it" theory.

    [i]It looks like Microsoft was informed of the IE zero day at the same time as everyone else ? namely, last Tuesday (Patch Tuesday).[/i]

    Just more FUD by the ABMers.
    ye
    • One example does not disprove that

      I give them full credit for their action on this problem and commend them for their speediness, but that does not mean they haven't and still aren't sitting on other problems that they've known about. The only thing MS has proven is that they did a good job in fixing this single exploit.
      Michael Kelly
      • It does when we're talking about this exploit.

        There were those claiming MS had been sitting on this vulnerability.

        The other vulnerabilities that they've been "sitting on" apparently aren't high priority otherwise they too would have been exploited.
        ye
        • You just know someone's going to mention...

          ...the one that took seven years to patch.

          You know, the one that didn't actually have a real life example since it was pretty much impossible to exploit.
          Sleeper Service
          • So what you're basically saying

            is MS can't be bothered to patch an exploit until someone actually starts exploiting it.
            frgough
    • OMG WOW!! ONE PATCH!!! HOLY CRAP!!!!

      I'm so impressed I'm upgrading all my XP machines to Vista and demanding everyone use IE7!!!

      Get lost loser.
      itanalyst2@...
      • You are still using XP??!!

        We have a new loser here. LOL!!
        LBiege
        • You're using Vista voluntarily?

          Pot, meet Kettle.
          masonwheeler
      • No surprise you have a reading comprehension problem.

        Go back and re-read what I wrote. Perhaps if you do it a few times you might actually understand.
        ye
        • Help me here

          I've reread your post 5 times and still don't get the point of it Ye.
          914four
  • RE: Microsoft's incredible IE patch turnaround

    "Researching, fixing, testing, and releasing a security patch within an eight day window is an incredible feat"

    No, it's the way it [b]should[/b] be done. Most patch jobs should be doable in a day, even. The ridiculously long patch cycles are nothing more than appeasing corporate whiners who worship schedules.
    CobraA1
    • "Should" be done?

      Which rock did you crawl out from under?
      "No, it's the way it should be done. Most patch jobs should be doable in a day, even. The ridiculously long patch cycles are nothing more than appeasing corporate whiners who worship schedules."
      A [b]day[/b]!!! which dream world are you living in? How many [i]thousands[/i] of applications need to be included in the testing process to make sure that this patch doesn't break them? You make me want to laugh and cry at the same time-you think that MS can create, test and release a patch in a [b]day[/b], yet you would be the first to deride MS should said patch [i]break[/i] anything.
      justanitguy
      • Yeah.

        "Which rock did you crawl out from under?"

        The one where bad guys release new exploits the same day or the day after the old exploits are fixed. The schedule made exploiting systems easier.

        "A day!!!"

        Yes.

        "How many thousands of applications need to be included in the testing process to make sure that this patch doesn't break them?"

        Zero. If your application relied on a bug in the OS to function, it was poorly designed. Microsoft is not responsible for the poor quality of other people's code.

        "yet you would be the first to deride MS should said patch break anything."

        False. If the patch breaks my app, I will blame the creator of my app.
        CobraA1
        • Sure.

          "If the patch breaks my app, I will blame the creator of my app."

          Ya sure you will. Just about anyone I have ever seen around here who blames an app creator for breaking, or for being incompatible with a Windows OS gets called a MS schill or troll. So if what you are saying is you look forward to being called names then maybe your telling the truth.

          And further, just saying that "If your application relied on a bug in the OS to function, it was poorly designed" doesn't cover the bases in this case. Sometimes a patch isn't simply like fixing a hole by plugging it, sometimes the hole requires a little bit of rebuilding around it because thats whats creating the hole. A good solid easy fix may have potential to interfere with some programs functionality or the particular way they interact with the OS and that takes some time to sort out, its just that straight forward.

          Think on it, its the OS thats getting the patch, there is almost always more then one way to patch a vulnerability. If there are two or three ways you could do it where the fix crashes an assortment of apps, or there is one or two ways it could be done that doesn't crash apps, it makes far more reasonable sense to have the OS producer figure it out before implementing the patch then to release the patch, have various and assorted apps crash and have the public get hit by that then have the assorted individual application producers figure it out and come up with their own assortment of patches to fix their own applications. Its just not practical or even makes sense.
          Cayble
    • Do you have a clue as to how complex this can be?

      Patching a complex system without breaking a ton of stuff is very difficult and in some cases requires wide disruptive changes. Really you have to be a developer to understand this.
      DevGuy_z
      • I am a developer.

        I am a developer, actually, and heaven knows I've seen my share of bugs, refactoring, and rewrites.

        Yes, it is *possible* to have a bug fix break stuff, but that's rare. What usually happened is that Microsoft included a lot of new code in addition to the bug fix, and that new code broke stuff.

        Vista and Windows 7 are also moving towards increased modularity, which should mean a reduced number of dependencies and side effects to worry about.

        There is some merit to your claim, yes, but the idea of a "cascading bug fix" that breaks other stuff is rare if all you're doing is fixing a bug. Usually it happens if you write a lot of new code in addition to fixing the bug.

        Unfortunately, Microsoft has a bad habit of including a lot of new code with their bug fixes, and that can indeed cause a lot of issues if the new code isn't thoroughly tested.
        CobraA1
        • RE: I am a developer

          And I am SOOOO glad that you're not on my team. On second thought, I'm also glad none of your QA guys are on my team. Mine would have slapped you up the side of the head. It is in fact COMMON for a bug fix to break functionality somewhere else unless you are careful.

          In the case of this patch, if they had accidentally broken the XML databinding feature in IE, countless websites (especially internal corporate ones) would have broken causing IT departments to NOT roll the patch; something potentially even more dangerous.
          Yensi717
          • Glad you're not on *my* team.

            For all the talk about "one bugfix breaking something else," if you know what you're doing and follow good coding practices (and get everything reviewed by another developer before check-in) it's actually extremely rare.

            As I understand it, this particular bug has to do with referencing memory that had already been freed. Fixing an error like that is a trivial matter once you manage to actually find the code that's causing it, and it doesn't cause much in the way of side effects unless some "clever programmer" idjit went and coded something that depends on it. (In which case it's their own fault for writing stupid code, and they need to fix it, not you.)

            Bottom line, it should have taken Microsoft one day to fix this, not 8.
            masonwheeler
          • Remember...

            [i] if you know what you're doing and follow good coding practices (and get everything reviewed by another developer before check-in) it's actually extremely rare. [/i]

            ...we are talking about Microsoft here.
            914four
        • You're caught

          You have two statements, one of which concretely disproves the other.

          First, you claim "I am a developer, actually..."

          Later, you say "Yes, it is *possible* to have a bug fix break stuff, but that's rare."

          Making that second statement proves that the first is not true. Any professional developer knows that statement is ludicrous.
          KTLA