Microsoft Makes Security Blunder with Vista Beta Patching
Think Microsoft issuing patches for Vista Beta software is good for security? Think again!
I recently ran across this blog entry
by Microsoft's Alex Heaton, where he posts Microsoft's position on patching the Windows Vista beta
The statement itself is just plain silly (more on this later), but this sentence in particular really threw me off: "We have received multiple inquires from Windows Vista beta testers asking if their systems are affected by the security bulletins released last week."
Other than pure curiosity, why would anyone ask such a question? Surely they don't think that the beta operating system they're running is "secure," do they? Do they have a functioning version of their chosen anti-virus, anti-spyware or personal firewall product supported by their respective vendors on Vista? Do they believe that Microsoft has corrected all security vulnerabilities in features that aren't being broadly tested? Do they believe that the third-party software they're running on the box properly interacts with Vista such that those products don't introduce other vulnerabilities of their own?
Why, if I'm not running the beta in production, would I have to worry about some worm getting onto a network where Vista is present?
The only answer has to be that they're running it in production, on production networks or exposed directly to the Internet.
According to a recent Information Week article written by Gregg Keizer, Michael Cherry, an analyst with Directions on Microsoft, says you can't test a beta product without putting it into a production environment. I say that if that's the only way you can figure out how to test a beta operating system, you shouldn't be testing it!
There will always be people who just think it's cool to run the next version of "Product X" before everyone else. They feel like they're an insider, part of a clique and see themselves as being able to help shape the destiny of that product. Fine, as long as you realize the fire you're playing with. If you've nothing to lose, then why not? But if you're concerned about what you've got on the box or what might attack it, then you've really got to ask yourself if that "coolness" is really worth it.
You could, for example, run into a situation where the entire operating system simply stops functioning with your machine. Say you update the drivers or firmware for some device attached to the system, only to find out it's not compatible with the beta operating system. What if that game you love to play happens to issue an update to fix a problem it has with Windows XP, but that same fix means that Windows Vista won't run it? Would you like to lose all of those valuable licensed MP3s you have because, say, Vista encounters a problem in its Digital Rights Management modules?
I could go on and on, but there will always be those who will run beta software regardless. So instead of trying to convince people not to run it, let me turn my attention to Microsoft's assertion they're going to maintain critical security patches for it during the beta process.
First, why do we want Microsoft to expend this energy? We want the operating system to be finished sooner, not later. Certainly we want Microsoft to patch vulnerabilities as they are discovered, but should it waste cycles dealing with the media as well as the beta testers who don't realize what they're running in order to quell fears that a piece of beta code might have a vulnerability?
If all of this is simply a way of beta testing the software update process in Vista, fine, but then state it as such. By giving people the impression they're running an operating system that will be secure by virtue of patches being made available for it, Microsoft completely muddies the waters regarding what beta testing an operating system should be seen as -- namely, a very insecure effort.
What happens if, as with Windows 95, on the day of release to the public announcements are made about vulnerabilities still present in the released code? With Microsoft saying it won't release patches for beta versions after the code goes RTM (released to manufacturing), anyone who doesn't immediately go out and get the new operating system, reformat their drive and install it may very well be vulnerable.
And if you're beta testing the "correct" manner, such an issue won't matter. You'll simply scrap the test machine's image and move on to testing something else. As it's not exposed to potential harm -- who cares if new malware is released attacking such vulnerabilities?
I'm convinced that Microsoft suggesting it will keep critical vulnerabilities patched on beta systems is only going to lead more people to think they can run beta code without the requisite fear they should have. Attacks will be created targeting beta code, and the beta process will become more cumbersome, both for Microsoft and the beta testers.
Another issue: During the beta process, there may be hundreds of builds, many released to focus on a specific issue. Sometimes the company will disable features, or enable features in an insecure fashion, to help testers and developers figure out a particular issue. Do we want Microsoft to reconsider doing this simply because people using the beta might be exposed to a security vulnerability? I don't, and I seriously doubt the majority of independent software vendors (ISVs) will want this either.
Now Microsoft has said it's going to be releasing these patches for Beta 2 and RC1. These are the beta builds released to the broader public audience. So some of my concerns won't apply to the interim builds before, between, and after these public builds. Regardless, how do we know we won't be seeing stories from beta testers who happen to get their hands on an interim, non-public, build? This happens all of the time, and should one decide to publish information about a vulnerability, we'll have that furor to deal with.
There have always been restrictions on what could be stated publicly about beta software. Publishing details about performance testing, for example, is typically not allowed because the software is often bloated with debugging and other code that might hinder performance. In my opinion, this should apply to security vulnerabilities, too.
To preserve administrator's arguments against their user's running beta code, I hope that Microsoft reconsiders this choice and find another way to handle the issue. Otherwise, all developers are going to be faced with having to make their code secure before it's even finished, a task I see as impossible to accomplish.
Russ Cooper is a senior information security analyst with Verizon Business, Inc.
He's also founder and editor of NTBugtraq, www.ntbugtraq.com,
one of the industry's most influential mailing lists dedicated to Microsoft security.
One of the world's most-recognized security experts, he's often quoted by major
media outlets on security issues.