Every so often, somebody gets the idea that computers should detect viruses in the same way that the human immune system detects bio-viruses. Faced with the problem of how to defend against unexpected computer viruses, it seems natural to emulate the body’s defenses against unexpected bio-viruses, by creating a “digital immune system.”

It’s an enticing idea – our immune systems do defend us well against the bio-viruses they see. But if we dig a bit deeper, the analogy doesn’t seem so solid.

The human immune system is designed to stave off viruses that arose by natural evolution. Confronted by an engineered bio-weapon, our immune systems don’t do nearly so well. And computer viruses really are more like bio-weapons than like evolved viruses. Computer viruses, like bio-weapons, are designed by people who understand how the defensive systems work, and are engineered to evade the defenses.

As far as I can tell, a “digital immune system” is just a complicated machine learning algorithm that tries to learn how to tell virus code apart from nonvirus code. To succeed, it must outperform the other machine learning methods that are available. Maybe a biologically inspired learning algorithm will turn out to be the best, but that seems unlikely. In any case, such an algorithm must be justified by performance, and not merely by analogy.

An “insecurity feature” is a product feature that looks like it provides security, but really doesn’t. Insecurity features can make you less secure, because they trick you into trusting something of value to a product that can’t properly protect it.

A classic example is the “Password to Modify” feature of Microsoft Word, as revealed recently on BugTraq by Thorsten Delbrouck-Konetzko. This feature allows a document’s author to establish a password that must be entered before the document can be modified. That would be a pretty useful feature – if Word actually provided it. But as Mr. Delbrouck-Konetzko revealed, it is easy for anybody to modify such a file without knowing the password. In other words, Password to Modify is an insecurity feature.

The flaw that caused this is pretty easy to understand. Word implemented the Password to Modify feature by storing the hash of the password at a special place in the Word document file. The problem was that there was nothing to connect the stored password-hash with the rest of the file, so there was nothing to stop somebody from moving a hashed password from one Word file to another. So suppose Alice created a file and put the password “A” on it. Bob could create his own file with password “B” and then copy his password into Alice’s file; then Bob could modify Alice’s file (since it contained his password, which he knew). For extra style points, when Bob was done he could copy Alice’s password back into the modified file.

Microsoft responded to this report by issuing a bulletin helpfully explaining that the feature was never really meant to provide security. The bulletin contains such statements as this:

Not all features that are found on the Security tab are designed to help make your documents and files more secure.

Unfortunately, Word’s user interface doesn’t do much of anything to help users distinguish insecurity features from real security features. For example, here is the relevant dialog box from my copy of Word 2000:



I’ve outlined the relevant area in red. The box on the left lets you establish a password to open the file; that’s a real security feature. The box on the right lets you establish a password to modify the file; that’s an insecurity feature. Nothing in the user interfaces tells you that the features provide very different levels of protection.

There’s another lesson here, in the fact that such an obvious problem exists in a popular Microsoft product, despite Microsoft’s recent focus on security, and despite all of the genuine security experts who work there. This flaw reflects a bad decision made by some non-expert programmer or manager a long time ago, a decision that has persisted for so long, one assumes, through sheer inattention and inertia. And it’s not only Microsoft who failed to notice this for so long. Any good cryptographer, on hearing a description of what the Password to Modify feature supposedly did, should have been very suspicious. The problem was there to see for a long time; but apparently nobody looked.