In an email message last week, I received a URL to a Web site on which I saw more than a dozen vulnerabilities in Microsoft products (19 as of September 16). Patches are either not available or offer insufficient protection. The most recent vulnerability was reported on September 9, 2002, and the oldest was reported on June 6, 2000.
The vulnerabilities include serious problems, such as exposing local files, sniffing Secure Sockets Layer (SSL) connections, installation and execution of arbitrary programs, breaching firewalls, elevation of privileges, and buffer overflows. Why aren't patches available for these problems? The answer is probably manifold.
Given that users reported some of the vulnerabilities last week, we can assume that Microsoft is working on patches to correct them. Other vulnerabilities do have available patches—but not for all versions of a product. For example, regarding two Microsoft Internet Explorer (IE) problems (cssText Local File Reading and DynSrc Local File detection, which relate to reading data from local files and determining whether certain files exist, respectively), patches are available for IE 6.0, but not for IE 5.x.
Microsoft released IE 6.0 some time ago and recently released Service Pack 1 (SP1) for that version. However, many users still have IE 5.x. Recent reports that show IE's presence on about 94 percent of all desktops also show that 48 percent of those users still have IE 5.x versions of the browser. Why do we lack patches for serious vulnerabilities in IE 5.x? We could infer that Microsoft wants users to "toe the line" and upgrade to IE 6.0 SP1.
According to "InfoWorld," Microsoft Windows Division Senior Vice President Brian Valentine recently made some rather startling statements. At the Windows .NET Server (Win.NET Server) 2003 developer conference, Valentine said, "I'm not proud. We really haven't done everything we could to protect our customers ... Our products just aren't engineered for security ... We realized that we couldn't continue with the way we were building software and expect to deliver secure products ... It's impossible to solve the problem completely, as we solve these problems there are hackers who are going to come up with new ones. There's no end to this."
Why would Microsoft admit somewhat apologetically that the company hasn't done all it could do for security? Given the constant barrage of security problems still being discovered, won't the company make significant security changes in its code base? Furthermore, won't Microsoft slow the rush of new products to market faster than we can adapt to the current products? Unfortunately, the answer is—probably not, especially given some of the company's latest technology announcements.
Microsoft recently announced its intention to create a hardware-based platform for security, code-named Palladium. Palladium will offload certain aspects of system security—aspects that have resided inside a user-controlled OS—onto Intel-developed hardware designed to work with Microsoft-sanctioned security technology.
Clearly, Palladium will, in some instances, relieve Microsoft of the burden of writing more-secure software. At the same time, the new security approach will put users in the uncomfortable position of choosing whether they should upgrade every computer and OS to continue "following" Microsoft by adopting Palladium. To help foster Palladium adoption, Microsoft will probably release yet another resource-intensive OS that couldn't possibly run well on users' existing hardware. And if the company also continues to forego releasing security patches for previous software packages, that will prod users even harder.
I have deep concerns about hardware-based security as the direction of the future. Bruce Schneier expressed the sentiments of many users quite clearly in a recent "Crypto-Gram" newsletter: "There's a lot of good stuff in \[Palladium\], and a lot I like about it. There's also a lot I don't like, and am scared of. My fear is that \[Palladium\] will lead us down a road where our computers are no longer our computers, but are instead owned by a variety of factions and companies all looking for a piece of our wallet. To the extent that \[Palladium\] facilitates that reality, it's bad for society. I don't mind companies selling, renting, or licensing things to me, but the loss of the power, reach, and flexibility of the computer is too great a price to pay."
Hacking Microsoft products is no longer about the white-hat angle of coaxing Microsoft to write better code and alerting users to vulnerabilities or the black-hat angle of attacking Microsoft. Right now, the more diligently hackers work to find security bugs, the more they support the eventual adoption of Microsoft Palladium, as well as other vendorcentric hardware-based security subsystems that will quickly make their way to market. (For more about Intel and VeriSign's recently announced processor-based authentication, for example, see the news story in this edition of the newsletter.)
If more severe security problems are discovered and reported—and we can assume they will be—that's fuel for the vendorcentric hardware security platforms of the near future. Conversely, if those security problems go undiscovered or unreported, users remain unknowingly at high risk. With the advent of Palladium, Microsoft benefits either way. But do we? It's a veritable Catch-22.
