Why did Microsoft wait 7 years to fix SMBRelay attack flaw?
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.
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.
[Source: zdnet]
Post a Comment