MS throttles research to conceal SW bugs
The truth will not set you free
Exclusive Microsoft Security Manager Scott Culp revealed unilateral steps the company has taken to throttle the exchange of vulnerability information relevant to their famously buggy products, clearly in hopes that patches and fixes can be fed to consumers discreetly, without ever realizing they've been at risk to attack.
During a presentation at the Trusted Computing Forum in Mountain View, California Thursday, Culp outlined the terms of several partnerships MS has pursued with compliant security vendors aimed at keeping the Redmond Beast's dirty laundry hidden from the public eye.
Briefly, the scheme requires vendors to withhold detailed security data and to suppress the exchange of exploit code, which, unfortunately, is the only means of verifying that a patch actually works.
Vendors will exercise "best efforts" to avoid disclosing details that can be used to exploit a vulnerability for a period of thirty days from the initial discovery.
After this grace period, or if the Blackhat community begins exploiting it sooner, "additional details" may be released. These details will of course not be sufficient to exploit the flaw, or to test the patch. We would expect the current Microsoft TechNet security bulletins to provide the model of what MS considers to be 'detailed information'.
There will be exceptions for the Feds, for recognized infrastructure protection organizations (ISACS), and "other communities in which enforceable frameworks exist to deter onward uncontrolled distribution."
Clearly, whenever there's fresh trouble, MS is hoping to get the matter resolved quietly and distribute the patches without alarming the public, or drawing attention to its appalling record of security engineering. Win-XP's aggressive auto-update feature will be the prime vehicle of behind-your-back patching, and the .NET initiative will be the needy beneficiary of the false sense of security which the company's new obscurity program will encourage.
The group of security vendors currently collaborating with MS includes some famous, and even ironic, names: @Stake, BindView, ISS, Foundstone, and Guardent. @Stake's Chris Wysopal ('Weld Pond'), an old L0pht denizen, will lead efforts to draft the framework for the new regime. We're much impressed to see how far the L0pht has, em, evolved.
The framework will involve "Members," defined as "Industry-leading companies actively engaged in security research and network defense, and leading software vendors."
Below them will be "Associate Members," defined as "Influential vendors and organizations within the security community who support the goals of the organization."
Finally, we'll have an "Advisory Board," defined as "Influential customers of the security community who support the goals of the organization."
What's wrong with this picture?
While it sounds like a common-sense proposal for limiting damage by restricting access to exploits, the effect of this scheme is likely to be an ironic reduction in security.
For one thing, lines are already being drawn within the security community. There are a number of highly-respected vendors who believe in full disclosure, and who regard Microsoft's partnership arrangement, in which they obviously won't be able to participate, as an assault on the way they do business. Effort will be wasted in fruitless conflict. Information will not be shared, and many talented people will be unable to contribute to the solution because they've not been approved by MS.
The debate over full disclosure is endless and insoluble. Opponents will never agree because there are, quite simply, excellent arguments to which responsible, intelligent, decent people on both sides of the divide adhere.
The two camps have coexisted uneasily, but tolerably, for decades. Now, on the rebound from its gross humiliations by Sircam, Code Red and Nimda, Microsoft has decided it can no longer coexist with the full disclosure camp. But they themselves are to blame for not doing adequate security engineering before releasing their products. They're blaming the messenger because the news so often reflects badly on themselves.
Add to this the fact that exploit code is the only tool for verifying that a workaround or a patch works as it should. Obstructing its dissemination means that non-approved security vendors will have a more difficult time testing their solutions.
When someone devises a security workaround, the first thing they do is attack their machine to see if it works. Ideally, one attacks it using as many exploits as one can find. If you have a vendor handling this for you, then its in your best interest to see that they've tested their solution as rigorously as possible. This requires an exchange of information. A apartheid system of 'approved' and 'rogue' security vendors is hardly beneficial to consumers of these services.
Because MS has moved in secret, making back room deals with a select few, it's possible that opponents of this scheme will be tempted to retaliate by aggressively searching for exploitable holes in MS products and publicizing the information widely, in order to demonstrate the futility of security through obscurity. Any such 'disclosure war' would only make end users less secure.
But the best and most dramatic example of the folly of obscurity is the recent fiasco with MS Passport session cookies, first reported by security researcher Marc Slemko. Millions of Passport users were open to an attack which could have revealed extremely sensitive personal and financial data.
In this case, Slemko did the right thing by publishing the exploit. Microsoft immediately disabled Passport services until a workaround could be implemented.
However, had MS handled it according to their new disclosure regime, all of those customers would have remained open to attack for up to a month, entirely innocent of the danger.
This works for Microsoft, which wants you to trust its many .NET services whether you ought to or not. It doesn't work for end users. MS would have tossed the dice hoping that the flaw wouldn't have been exploited before they got it fixed. But the extremely sensitive nature of the information at risk in this case means that even a fairly safe bet is a bad idea.
By publishing the exploit Slemko ensured that MS would move immediately; and furthermore, he demonstrated the relative ease with which a session can be hijacked. Now users of these services will be a good deal more cautious about the sort of information they'll trust to Microsoft. Surely, we're all better off knowing that Passport is essentially insecure.
Your Mum was right; honesty really is the best policy. ®
Sponsored: Becoming a Pragmatic Security Leader