Why did Microsoft wait 7 years to fix SMBRelay attack flaw?

Why did Microsoft wait 7 years to fix SMBRelay attack flaw?

Summary: One of the code execution vulnerabilities fixed in this month's Microsoft Patch Tuesday release dates back to 2001 when it was first disclosed by Cult of the Dead Cow hacker Sir Dystic (pictured left).If that wasn't cause for worry, get this:  An exploit for the bug -- in the way that Microsoft Server Message Block (SMB) Protocol handles NTLM credentials -- has been part of the Metasploit hacking tool since July 2007.

SHARE:
TOPICS: Security, Microsoft
71

Micosoft takes 7 years to fix SMB Relay vulnerabilityOne of the code execution vulnerabilities fixed in this month's Microsoft Patch Tuesday release dates back to 2001 when it was first disclosed by Cult of the Dead Cow hacker Sir Dystic (pictured left).

If that wasn't cause for worry, get this:  An exploit for the bug -- in the way that Microsoft Server Message Block (SMB) Protocol handles NTLM credentials -- has been part of the Metasploit hacking tool since July 2007.

So, why did it take Microsoft seven years to fix something that could lead to full system takeover?

Microsoft's Christopher Budd explains:

When this issue was first raised back in 2001, we said that we could not make changes to address this issue without negatively impacting network-based applications. And to be clear, the impact would have been to render many (or nearly all) customers’ network-based applications then inoperable. For instance, an Outlook 2000 client wouldn’t have been able to communicate with an Exchange 2000 server. We did say that customers who were concerned about this issue could use SMB signing as an effective mitigation, but, the reality was that there were similar constraints that made it infeasible for customers to implement SMB signing.

[ SEE: Responsible disclosure, the Microsoft way ]

Sisk said the case was never closed and investigations continued over the years to determine if there was a way to fix the bug without requiring developers to completely rewrite applications.

Over the course of the past year, however, that ongoing work showed us a way to build on those incremental changes that we believed would enable us to make changes that address the issues outlined in the SMBRelay attack and also minimize the impact on network applications. If we were able to do that, we would be able to look at addressing this issue not in a new version of Windows but instead in a security update, provided it met the appropriate quality bar.

Our engineering teams spent a great deal of time testing this approach and found it was feasible. We then took that work and developed it into a security update, putting it through our standard testing to ensure it met an appropriate level of quality for broad release. What we released today with MS08-068 is that security update. It addresses the SMBRelay issue but does so in a way that doesn’t have the negative impact on applications that we originally believed addressing this issue would have.

[ SEE: Where on earth are these Microsoft patches? ]

Microsoft wasn't alone discussing attack paths to this old vulnerability.  In 2003, on the Full Disclosure mailing list, there's evidence of public discussion of the issue and a note by Dave Aitel that it was already part of a previous DefCon presentation.

Microsoft has done an amazing job of improving its security response process but these time-to-patch hiccups continue to be a major source of worry.    I've documented several times in the past when Microsoft failed to fix issues in a timely -- and responsible -- manner and these examples only highlight one of the company's biggest security weakness.

Oh, by the way, there's another outstanding issue collecting cobweb.   This 'token kidnapping' issue was first discussed in March 2008 and, after a bit of hemming and hawing, confirmed in this Microsoft security advisory.   Exploit code for this privilege escalation vulnerability was publicly released last month.

Microsoft knows all this.

We are still waiting on a patch.

Topics: Security, Microsoft

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

Talkback

71 comments
Log in or register to join the discussion
  • Sour over mis-predicting the patches this month?

    First off, does anyone proof-read these posts? Multiple typos/grammatical errors make it look like this was rushed out... Anyway.

    Mentioning the token-kidnapping issue makes me wonder if Ryan is sour that his patch prediction (on Twitter) was wrong?
    cypherpunk@...
    • prediction

      It was more of a hope than a prediction.

      _r
      Ryan Naraine
      • So what was your solution?

        patch the vulnerbility in 2001? That effects everybody's network.

        How do you fix that issue then?
        GuidingLight
        • Fix it!

          There was a fix, it was fixed, simply put, MS dug their own hole by integrating too much into the OS making it VERY HARD to fix the problem, which is at best, an excuse.

          TripleII
          TripleII-21189418044173169409978279405827
          • I agree with your assessment

            The kernel in NT 3.1 was only 64k, but it has grown exponentially since then as more and more is added. Somewhere along the way Microsoft got lost...
            914four
          • Erm ... nope!

            The kernel ... the core of the Windows OS ... the stuff that runs in Ring0 ... has indeed grown.

            It's grown to support 64-bit CPU's, NUMA architectures, provide better scalability and supportability and to better expose a pluggable architecture for device drivers (e.g. graphics, network, etc) enabling new drivers to be added without requiring the OS to be recompiled and redistributed.

            The Kernel, however, is not the OS. When you use an OS, you're using user-mode code running in Ring2. This user mode code (Win32) may eventually call into the kernel for important services, but your user-mode apps will rarely know about this.

            Vista's disk footprint grew enormously from XP because it includes a MOUNTAIN of drivers that are copied onto your HDD (HDD space is cheap and plentiful) so you don't have to go find your Vista install disk every time you plug in a new device.
            de-void-21165590650301806002836337787023
          • Did you get it?

            Since he referenced the NT 3.1 kernel as 64KB, I'm pretty sure he knew that the kernel wasn't the OS. The 3.1 OS was significantly larger than that. Did you just miss his point completely?
            daengbo
          • Still doesn't change the the issue

            if [i]integrating too much into the OS making it VERY HARD to fix the problem[/i] was the issue, it still doesn't change the fact that there wasn't an easy fix.

            Like building 30 walls in front of your plumbing: if a leak is found, it doesn't matter why those other 29 walls were built, the problem is that they're still in your way, keeping you from easily fixing the plumbing.
            AllKnowingAllSeeing
          • That depends.

            If the walls were built to make it more difficult for you to hire another plumber then they are relevant.
            914four
        • One Size Fits All

          [i]patch the vulnerbility in 2001? That effects everybody's network.[/i]

          The only way that a fix would affect "everybody's network" would be if Microsoft themselves depended on the vulnerability.

          In which case, MS could remove the dependence first now, couldn't they?

          On the other hand, if it was a matter of "some user applications depend on the vulnerability" then just leaving it there resulted in making the whole mess worse.

          The rational approach would have been to take a multi-step plan:
          1) Remove MS dependence on the bug. Publish the roadmap.
          2) Add a fix, with a switch to enable the fix. Off by default.
          3) Make the switch disabling the bug on by default.
          4) Remove the bug for good.

          I'm having a [b]really[/b] hard time seeing that course lasting seven years. Considering all of the regressions that MS has dropped on the world without nearly this agony, it's hard to believe that they've been losing sleep over this one.
          Yagotta B. Kidding
          • Well, they were busy

            creating DRM for Vista. They got around to it eventually...
            914four
          • You do know what SMB is, right?

            SMB is the TCP of enterprise networks. SMB is a networking protocol used by Windows to allow you to load & save files from/to network shares, allows Outlook to talk to Exchange, etc.

            The original solution to this issue was to modify every app that communicated via the network. That includes not only MS's apps, but also every 3rd party app, service and system.

            Now, while the vulnerability was identified around 2001, note that the actual exploit didn't arrive until 2007! That gives you some idea about the difficulty with exploiting this issue.

            Now imagine the complexity of fixing it - fixing an exploit is MUCH harder than creating the exploit itself!

            That MS took the time to fix this without causing a massive worldwide multi-vendor patchin effort is an amazing feat for which they should be congratulated, not pilloried.
            de-void-21165590650301806002836337787023
          • Get real

            SMB was Microsoft's attempt to own networking through Windurs client install base. It's simply ridiculous that we live in an environment where a Corporation believes it is ok to behave that way, which results in these problems ...

            What price greed?
            fr0thy2
        • You don't....

          ...when it gets killed by every firewall - including Windows firewall - and can therefore only be run internally at which point the corporate anti-virus nukes it.
          Sleeper Service
    • Sour over MS's security incompetence more like it.. <NT>

      NT
      AzuMao
    • Twitter?

      Why should anyone care what happens on twitter? Make as much sense
      to declare war over a water-cooler comment.
      Resuna
  • Statistics

    Keep in mind, issuing a patch for these bugs really screws up their comparative bug statistics. As long as they just leave the old bugs unfixed, they have much better time-to-patch than their competitors do.

    So let's not dump on them for fixing the really ancient security holes; it's hurting them pretty badly on the statistics.
    Yagotta B. Kidding
  • What forest?

    Is the answer staring us in the face? Microsoft is the biggest software house and employs many of the brightest programmers in the World. So why do they lag so terribly in fixing these security holes? The reason they don't to fix the security holes any faster is because they can't.
    kozmcrae
  • Ryan is Archie Bunker

    Hey Ryan, since you can sit in your arm chair and criticize everyone so well, why didn't you fix it? Why aren't all the bugs from all the large corporations all fixed - Ryan says they should be! Give me a break Ryan. Your a hack and don't even know it. How about you go take a class at your local community college about programming.
    FireThorn
    • The answer is so very simple Einstein!

      How the hell can he fix it if he doesn't have access to the source code? Come on Einstein answer up! Moron, now if it was Open Source your idiotic diatribe would be more accurate... ]:)
      Linux User 147560