MS08-068 and SMBRelay

Hi, this is Christopher Budd.

We’ve received some questions from customers about MS08-068 and its relationship to an issue that was first discussed in 2001, called the SMBRelay attack.

Specifically, we’ve gotten some questions about why, in 2008, we’re releasing an update that addresses an issue first discussed in 2001. Since I was in the MSRC back in 2001 when this was all first discussed, I feel well placed to answer that.

At a high level, the behavior that was discussed in the original SMBRelay attack is related to some of the basic behavior of the legacy NTLM protocol. 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.

After saying that, though, the matter wasn’t closed for us. Since then we’ve been looking at this issue to see if there’s a way we can address this issue that doesn’t have such a large impact to applications and also doesn’t require application developers to completely rewrite their applications. In general, changes of this magnitude can only be made safely in completely new versions of Windows because of the thorough testing that would would receive. And we’ve made some incremental changes in things like Windows XP SP2 and Windows Vista to help address some of this issue.

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.

As Mark notes in his post, implementing SMB signing is still an option and one that we ultimately recommend. However, if you’re like me and remember the SMBRelay attack, you now have a protection option in case you can’t implement SMB signing: apply MS08-068.I hope this helps give some more background on this.



*This posting is provided “AS IS” with no warranties, and confers no rights*