In the wake of the Blaster worm—an infestation I had been unaware of due to not using Windows and, as far as I can tell, being out of town recently—Scott Rosenberg points at “Patch and Pray”, an article examining the increasingly sketchy method of patching software to close security vulnerabilities, using the history of the SQL Slammer worm as an illustration of the problems facing managers today.
Since Slammer struck several months after Microsoft released a patch closing the vulnerability, one might think poorly on the people who hadn’t properly protected their systems, but the situation is naturally more complex than that. Applying patches has its own risks, like unexpected conflicts between a patch and some critical application software or the possibility that it might incorporate older code and effectively unpatch a previously fixed problem. (That actually happened! Read the article for more details.)
For whatever reason, I don’t see this happening as much in the Mac OS X world. Perhaps that’s my inattention, perhaps it’s because Apple’s installed base is a smaller target, or perhaps it’s because BSD Unix is less vulnerable (although not invulnerable). I don’t know. But we certainly don’t see the flood of security patches that I hear about in the Windows world.
Software patching is inherently risky, especially when there are multiple, independently-developed patches involved. In some ways, this is less effective than plastering over a crack in the wall: at least the plaster is unlikely to react badly with your paint and cause your toaster to explode. We can’t even be certain that starting over with new software will work, since we still haven’t managed to eliminate problems like buffer overflows despite knowing about them for decades.
As I see it, part of the problem—a small part, possibly, but an important one—is that our computers trust our software too much. In multi-user systems, you have the concept of permissions, where each user has authority to perform certain actions, like reading or deleting a particular file. I can deny you permission to look at my files, or I can let you read but not modify, and so forth. The problem is that any program I run is automatically granted my authority, so if I’m running notably virus-prone Microsoft Word, it can do anything I can do, like “accidently” delete my files or send indecent e-mail to my aunties. The question is, why should a word processor have this much power? Really, all Word needs to edit a file is permission to access and modify that particular file (also, it should be able to maintain settings information, but that’s a gimmie).
Now, there is some protection against catastrophic screw-ups in modern operating systems. There are certain areas of my computer that I—and therefore any software running in my name—cannot access without first providing an administrator password. Thus, I’m protected from, say, a rogue spelling checker trying to wipe out the operating system. But it’s free to delete every seventh letter from my class notes.
What we need are:
- The ability to parcel out authority in smaller packages
- The ability to give software we’re running less authority than we possess
- Something watching in the background that keeps track of what’s normal operation and lets us know when something weird is going on
I don’t expect any of this to happen overnight. I suspect that changing the system to allow every program I run to have different authority will be a headache for someone, and I expect the first attempts will be a pain in the neck to configure. (How often have you fiddled with your web browser’s security settings?) But I’ll be disappointed if we don’t start taking some steps to improve the situation.