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

Holes in the Armor 255 any per-user CPU time quotas. With a per-user process limit set at 50, those 50 processes from the attacking the user will quickly swamp the computer and stop all useful work on the system.) System Usage Is Not Monitored Ever have a Unix computer inexplicably slow down? You complain to the resident Unix guru (assuming you haven’t been jaded enough to accept this behavior), he’ll type some magic commands, then issue some cryptic state- ment such as: “Sendmail ran away. I had to kill it. Things should be fine now.” Sendmail ran away? He’s got to be kidding, you think. Sadly, though, he’s not. Unix doesn’t always wait for an attack of the type described above sometimes it launches one itself, like firemen who set fires during the slow season. Sendmail is among the worst offenders: sometimes, for no reason at all, a sendmail process will begin consuming large amounts of CPU time. The only action that a hapless sysadmin can take is to kill the offend- ing process and hope for better “luck” the next time. Not exciting enough? Well, thanks to the design of the Unix network sys- tem, you can paralyze any Unix computer on the network by remote con- trol, without even logging in. Simply write a program to open 50 connections to the sendmail daemon on a remote computer and send ran- dom garbage down these pipes. Users of the remote machine will experi- ence a sudden, unexplained slowdown. If the random data cause the remote sendmail program to crash and dump core, the target machine will run even slower. Disk Overload Another attack brings Unix to its knees without even using up the CPU, thanks to Unix’s primitive approach to disk and network activity. It’s easy: just start four or five find jobs streaming through the file system with the command: % repeat 4 find / -exec wc {} \ Each find process reads the contents of every readable file on the file sys- tem, which flushes all of the operating system’s disk buffers. Almost immediately, Unix grinds to a halt. It’s simple, neat, and there is no effec- tive prophylactic against users who get their jollies in strange ways.