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-
254 Security of-service attacks. Unix was created in a research environment in which it was more important to allow users to exploit the computer than to prevent them from impinging upon each other’s CPU time or file allocations. If you have an account on a Unix computer, you can bring it to a halt by compiling and running the following program: main() { while(1){ fork() } } This program runs the fork() (the system call that spawns a new process) continually. The first time through the loop, a single process creates a clone of itself. Next time, two processes create clones of themselves, for a total of four processes. A millimoment later, eight processes are busy cloning themselves, and so on, until the Unix system becomes incapable of creating any more processes. At this point, 30 or 60 different processes are active, each one continually calling the fork() system call, only to receive an error message that no more processes can be created. This program is guaran- teed to grind any Unix computer to a halt, be it a desktop PC or a Unix mainframe. You don’t even need a C compiler to launch this creative attack, thanks to the programmability of the Unix shell. Just try this on for size: #!/bin/sh $0 & exec $0 Both these attacks are very elegant: once they are launched, the only way to regain control of your Unix system is by pulling the plug because no one can run the ps command to obtain the process numbers of the offending processes! (There are no more processes left.) No one can even run the su command to become Superuser! (Again, no processes.) And if you are using sh, you can’t even run the kill command, because to run it you need to be able to create a new process. And best of all, any Unix user can launch this attack. (To be fair, some versions of Unix do have a per-user process limit. While this patch prevents the system user from being locked out of the system after the user launches a process attack, it still doesn’t prevent the system from being rendered virtually unusable. That’s because Unix doesn’t have
Previous Page Next Page