Holes in the Armor 251 A trusted path is a fundamental requirement for computer security, yet it is theoretically impossible to obtain in most versions of Unix: /etc/getty, which asks for your username, and /bin/login, which asks for your pass- word, are no different from any other program. They are just programs. They happen to be programs that ask you for highly confidential and sensi- tive information to verify that you are who you claim to be, but you have no way of verifying them. Compromised Systems Usually Stay That Way Unix Security sat on a wall. Unix Security had a great fall. All the king’s horses, And all the king’s men, Couldn’t get Security back together again Re-securing a compromised Unix system is very difficult. Intruders usually leave startup traps, trap doors, and trojan horses in their wake. After a secu- rity incident, it’s often easier to reinstall the operating system from scratch, rather than pick up the pieces. For example, a computer at MIT in recent memory was compromised. The attacker was eventually discovered, and his initial access hole was closed. But the system administrator (a Unix wizard) didn’t realize that the attacker had modified the computer’s /usr/ucb/telnet program. For the next six months, whenever a user on that computer used telnet to connect to another computer at MIT, or anywhere else on the Internet, the Telnet program captured, in a local file, the victim’s username and password on the remote computer. The attack was only discovered because the computer’s hard disk ran out of space after bloating with usernames and passwords. Attackers trivially hide their tracks. Once an attacker breaks into a Unix, she edits the log files to erase any traces of her incursion. Many system operators examine the modification dates of files to detect unauthorized modifications, but an attacker who has gained superuser capabilities can reprogram the system clock—they can even use the Unix functions specifi- cally provided for changing file times. The Unix file system is a mass of protections and permission bits. If a sin- gle file, directory, or device has incorrectly set permission bits, it puts the security of the entire system at risk. This is a double whammy that makes it relatively easy for an experienced cracker to break into most Unix systems,

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.”