252 Security and, after cracking the system, makes it is relatively easy to create holes to allow future reentry. Cryptic Encryption Encryption is a vital part of computer security. Sadly, Unix offers no built- in system for automatically encrypting files stored on the hard disk. When somebody steals your Unix computer’s disk drive (or your backup tapes), it doesn’t matter how well users’ passwords have been chosen: the attacker merely hooks the disk up to another system, and all of your system’s files are open for perusal. (Think of this as a new definition for the slogan open systems.) Most versions of Unix come with an encryption program called crypt. But in many ways, using crypt is worse than using no encryption program at all. Using crypt is like giving a person two aspirin for a heart attack. Crypt's encryption algorithm is incredibly weak—so weak that several years ago, a graduate student at the MIT Artificial Intelligence Laboratory wrote a program that automatically decrypts data files encrypted with crypt.2 We have no idea why Bell Laboratories decided to distribute crypt with the original Unix system. But we know that the program’s authors knew how weak and unreliable it actually was, as evidenced by their uncharacter- istic disclaimer in the program’s man page: BUGS: There is no warranty of merchantability nor any warranty of fitness for a particular purpose nor any other warranty, either express or implied, as to the accuracy of the enclosed materials or as to their suitability for any particular purpose. Accordingly, Bell Telephone Laboratories assumes no responsibility for their use by the recipient. 2Paul Rubin writes: “This can save your ass if you accidentally use the “x” com- mand (encrypt the file) that is in some versions of ed, thinking that you were expecting to use the “x” command (invoke the mini-screen editor) that is in other versions of ed. Of course, you don’t notice until it is too late. You hit a bunch of keys at random to see why the system seems to have hung (you don’t realize that the system has turned off echo so that you can type your secret encryption key), but after you hit carriage-return, the editor saves your work normally again, so you shrug and return to work.… Then much later you write out the file and exit, not realizing until you try to use the file again that it was written out encrypted—and that you have no chance of ever reproducing the random password you unknown- ingly entered by banging on the keyboard. I’ve seen people try for hours to bang the keyboard in the exact same way as the first time because that’s the only hope they have of getting their file back. It doesn’t occur to these people that crypt is so easy to break.”

Holes in the Armor 253 Further, Bell Laboratories assumes no obligation to furnish any assis- tance of any kind whatsoever, or to furnish any additional informa- tion or documentation. Some recent versions of Unix contain a program called des that performs encryption using the National Security Agency’s Data Encryption Standard. Although DES (the algorithm) is reasonably secure, des (the program) isn’t, since Unix provides no tools for having a program verify des’s authenticity before it executes. When you run des (the program), there is no way to verify that it hasn’t been modified to squirrel away your valuable encryption keys or isn’t e-mailing a copy of everything encrypted to a third party. The Problem with Hidden Files Unix’s ls program suppresses files whose names begin with a period (such as .cshrc and .login) by default from directory displays. Attackers exploit this “feature” to hide their system-breaking tools by giving them names that begin with a period. Computer crackers have hidden megabytes of information in unsuspecting user’s directories. Using file names that contain spaces or control characters is another pow- erful technique for hiding files from unsuspecting users. Most trusting users (maybe those who have migrated from the Mac or from MS-Win- dows) who see a file in their home directory called system won’t think twice about it—especially if they can’t delete it by typing rm system. “If you can’t delete it,” they think, “it must be because Unix was patched to make it so I can’t delete this critical system resource.” You can’t blame them because there is no mention of the “system” direc- tory in the documentation: lots of things about Unix aren’t mentioned in the documentation. How are they to know that the directory contains a space at the end of its name, which is why they can’t delete it? How are they to know that it contains legal briefs stolen from some AT&T computer in Walla Walla, Washington? And why would they care, anyway? Security is the problem of the sysadmins, not them. Denial of Service A denial-of-service attack makes the computer unusable to others, without necessarily gaining access to privileged information. Unlike other operat- ing systems, Unix has remarkably few built-in safeguards against denial-