Know the Risk: Digital Transformation's Impact on Your Business-Critical Applications REGISTER >
What's the big deal, you ask? Plenty.
As I write this, the private patch is available and being downloaded (no doubt) by thousands of people. I've even seen discussions by companies considering deploying this private patch across their enterprises. Microsoft's patch to the same problem isn't scheduled to be released for about a week.
There are a myriad of problems with this scenario. Let's consider them a bit...
The potential for releasing a flawed 'solution' is vast. But that's still not all of what made this particular vulnerability such a big deal.
Add to the difficulties of merely having to produce a suitable solution to the problem the fact that someone else beat them to the punch. A private, no doubt well-intended person wrote and distributed his own version of a patch to this Microsoft defect more than a week before the Microsoft patch is due to arrive. Now consider the complexities of the situation.
Will the Microsoft patch work with the private one? Will it replace it? If the private patch causes application software to fail, will Microsoft's customer support lines start ringing? (You betcha!) Will the private patch cause unforeseen compatibility issues six months or a year from now? Who knows? Even if that private patch is perfect in every way, how will it impact Windows Update and other configuration management concerns? Who knows.
On the other hand, what if there's something nasty in the private patch -- a bug, spyware, or a rootkit of some sort, perhaps? How do we know it is trustworthy? Because the author says it is? Because a well-known security expert said on his podcast that he personally verified the source code and can vouch for it? How do we know that even the vetted source code corresponds to the binary patch on the download site? Who knows?
Don't get me wrong. I'm really not trying to say that this kind soul who produced the private patch did something terrible. Everything that I have heard points to the author being respectable, trustworthy, and trying to perform a meaningful public good. Kudos!
The real failure here is the system, not the particular individuals involved. For starters, publishing a zero-day exploit is unconscionable. Those responsible should be punished to the fullest extent of the law. Our patch-and-chase cycle is broken. We've got to do much better. The vulnerability that I'm talking about was caused by a buffer overrun in the way that Microsoft Windows handles media files. Buffer overruns (or overflows, if you prefer) are preventable implementation defects in software that should have been caught by the vendor before the product's release. We've got to get more serious about how we do software security -- and how we consumers accept product releases for that matter.
And when product defects do make it through the Quality Assurance process, we've got to find better ways to engineer solutions. In the unfortunate case of similar zero-day issues, we need to find some stop-the-bleeding countermeasures, followed by properly engineered and tested solutions that fully fix the underlying defect. (In this case, a stop-the-bleeding workaround was presented, but it fell far too short of being useful.)
I don't mean to trivialize these issues. They're major and they're not going to be solved over night -- or in this column, for that matter. I do hope, though, that this particular case has opened up enough eyes that we can bring the right consumer and product vendor resources to bear on the problem and really come up with a solution that will work.