Microsoft finally catches the eight year bug

Microsoft Windows systems use the Server Message Block application level network protocol to provide sharing capabilities for files, printers, and other resources. SMB is supported on many other operating systems, primarily by way of the open source Samba project, but most of the time non-Microsoft OSes use SMB only when they must be integrated into a network that also includes MS Windows systems.
In March 2008, Josh Buchbinder published proof of concept exploit code for an SMB relay attack vulnerability in Microsoft’s implementation of the Server Message Block protocol. Since that time, a number of security testing tools have become capable of exploiting this vulnerability. According to Microsoft, “Public tools, including a Metasploit module, are able to perform this attack.” The result is that for several years now it has been possible to exploit this vulnerability entirely via code written by other people and freely available on the Internet.
The vulnerability was discovered even before March 2007, though. Christien Rioux announced discovery of this flaw in the Microsoft implementation of SMB at DEFCON in 2000. That means this flaw was first discovered and announced at least 8.25 years ago.
Microsoft finally released a patch for the vulnerability two days ago.
I think this is a good time for some reminders about what constitutes good security practice for software vendors. First of all, you should probably refresh your memory with my article from last month, 5 characteristics of security policy I can trust. In it, I pointed out the following characteristics of good security policy:
Full Disclosure
Open Development
Open Formats
Privacy Friendly
(Good) Vulnerability Management
On that last subject — good vulnerability management — I have written a few other articles that are relevant:
There’s more to security than counting vulnerabilities: The number of discovered vulnerabilities alone provides no useful information about the security of the software. A far more useful metric, if you must select one in a vacuum, would be how the developer responds to vulnerability discovery. The SMB vulnerability that took Microsoft more than eight years to patch is a pretty good indicator that Microsoft is a pretty poor choice for a vendor to trust.
Why there’s no such thing as a trusted brand: Corporations are not people. They do not have anything approaching an intrinsic, individual character. The only characteristics that are essentially unchanging in a given corporation are the characteristics that are necessarily intrinsic to all corporations, by their very nature. Everything else can change — and that means no corporation is really “trustworthy”. Don’t place your trust in the vendor. Demand proof. Sometimes, “proof” means “source code”, and if you can’t compile the source yourself, but are only allowed to read source code that someone assures you is the same as what was used to produce a binary that is handed to you separately, you still haven’t really seen proof of anything meaningful.
The truth about viruses: Large, corporate software vendors tend to have policies that are optimized for the security of a revenue stream, and not for the security of the customer’s data. An entire class of vulnerabilities, in the form of those primarily of use to viruses, is ignored and left unpatched by vendors like Microsoft. It is simply assumed that the slack will be taken up by antivirus vendors. Take heed of this behavior in a corporation, and realize what it means; given the opportunity, that vendor will ignore a vulnerability rather than fix it.
Obscurity is not security: Pretending something doesn’t exist doesn’t make it safe from malicious security crackers. If security researchers can discover a vulnerability, so can unsavory individuals who actually want to use an exploit for personal gain or to wreak havoc, rather than just using it to demonstrate a vulnerability that should be fixed.
How should we handle security notifications?: When you get notification of a vulnerability in your software, thank the person who discovered it. Fix the bug. Whatever you do, don’t punish people for giving you information that can help, unless you actually want to be the absolute last person to find out about vulnerabilities in your software in the future. Let your users know about the vulnerability, especially if you won’t be able to fix it quickly, so they can take steps to protect themselves.
This vulnerability is no minor, inconsequential issue. It can be leveraged to take control of a machine without knowing the password. According to the Microsoft Security Bulletin for this issue:
The vulnerability could allow remote code execution on affected systems. An attacker who successfully exploited this vulnerability could install programs; view, change, or delete data; or create new accounts with full user rights.
If nothing else, at least take this piece of advice if you’re a software vendor:
Don’t wait more than eight years to fix a vulnerability that allows someone to remotely gain control of the entire system without even knowing or cracking the password. That’s just irresponsible. Note: Thanks to Sterling Camden, of TR’s own IT Consultant Weblog, for the inspiration to write this article.