Every week or two, it seems, another Windows security flaw is detected. Microsoft has promised that Vista, the next release of Windows, will be more secure, but independent observers are skeptical. Microsoft has been declaring their systems to be more and more secure for years now, and yet hackers keep finding vulnerabilities. Despite pouring hundreds of millions of dollars and tens of thousands of programmer and test hours into security, Microsoft has not fixed the flaws in their flagship product. Why is it so hard for them to get this right?
Some Macintosh or Linux partisans would answer by saying things like “Microsoft doesn’t care,” or “Microsoft employees are idiots.” These answers are of course nonsense. Microsoft is sincerely trying to fix their system. The Microsoft OS group has a large number of very clever, capable, hard-working engineers. Some of the world’s best computer scientists work at Microsoft Research. The chief designer of Windows NT, the forerunner of modern versions of Windows, was David Cutler, who was also the chief architect of the VMS operating system, which was very successful and highly secure. Security was one of the goals for NT, and has remained a priority ever since. Even so, Microsoft has had trouble securing Windows.
Building a secure operating system turns out to be genuinely hard. Security bugs are found in the Macintosh operating system and in Linux nearly as often as in Windows. The root problem is not carelessness, but that there is not a reliable methodology for detecting security vulnerabilities. Testing in the usual sense turns out to be unhelpful. Testing software is a good way to check if the system operates normally, but a security flaw does not prevent normal operation until the flaw is actually exploited by an adversary. While there are tools that help, finding a security problem all too often requires some poor engineer to stare at the program’s source code for hours before noticing a vulnerability.
Alas, many software bugs can’t be traced to a specific line or small region of code, but instead are the result of a subtle mismatch in the assumptions made in different parts of the system. For instance, a programmer writing one block of code might assume that a user has permission to write a given file, and then a different programmer, or the same one months later, might assume that that code checks the file permissions and rejects bad requests. As a result of this mismatch, it might be possible for a user to write a file they shouldn’t be able to. This is a serious flaw because an intruder who can modify critical operating system files on disk can seize control of the system. Bugs like this, though, can’t easily be caught by reading over individual sections of the program since each section is correct in isolation. Since neither testing nor reading code exposes bugs of this sort, they can lurk undetected for years.
These sorts of issue will come up in any effort to build a secure operating system. Some of Microsoft’s security problems, alas, are a result of their particular corporate history and culture. For many years, Microsoft has worked on the model of “ship something that’s pretty good now, and fix it later.” This model has been enormously successful in the marketplace, but can result in software developers relying on the behavior that’s “almost right,” and then it becomes impossible to change the behavior without breaking a lot of existing programs. With security, “almost right” isn’t good enough, and if applications rely on OS features that are intrinsically insecure, the security hole is difficult to close.
For instance, all current versions of Windows were designed so that, by default, the computer’s primary user has the right to do anything to the computer. This means that if you, the primary user, inadvertently run a malicious program, that program has the right to do anything it pleases — including install a “rootkit” that will allow a hacker unlimited access to your machine. Microsoft should have changed this behavior years ago, but many current programs rely implicitly on having so-called Administrator privileges, and so simply having the default account lack such privileges would cause a great deal of trouble for users. Microsoft has of late decided to accept the pain of breaking existing software and will fix this behavior. Unless Microsoft changes its mind, Windows Vista, when it is finally released in 2007, will follow Apple’s example, and do what the Macintosh does: require a user to type in a password and explicitly approve each sensitive operation before doing it. This essentially grants administrator rights only on an as-needed basis.
Another problem is that Windows is simply too big to be easily secured. Microsoft keeps adding features, often without exhaustive testing and inspection. A large fraction of Windows vulnerabilities can be traced to obscure subsystems of the operating system that were added at one point and that then became obsolete and ceased being a priority for the developers. Put bluntly, Microsoft’s business model means that Windows has quite a lot of bug-ridden features that most users will never need but that are available for intruders to exploit.
Building secure operating systems with current techniques is a genuinely difficult engineering problem. We don’t currently have reliable methods for doing so the way that we do for, say, building bridges. Microsoft certainly bears some blame for a corporate culture that contributes to problems and for poor design decisions in the past. Before condemning Microsoft too strongly, though, it is worth remembering that the problem they are confronting is a genuinely difficult one, and that nobody else has yet solved it.
Ari Rabkin is a graduate student in Computer Science. He can be contacted at asr32@cornell.edu [1]. Between the Lines appears Thursdays.
Links:
[1] mailto:asr32@cornell.edu