Fork bombs

These are basically variants of the code snippet above. For instance, fingerd (the server for network finger requests) lets a client query all users on a host by using

finger @hostname

It also allows forwarding by using

finger @hostB@hostA

The way this was implemented is that the fingerd server process strips off the trailing @hostB and run finger @hostA. Consider a nasty attacker fingering @127.0.0.1@victimhost. This will cause the finger daemon at victimhost to query for all users on host 127.0.0.1. This will cause another connection to the victim's finger service to be established, which starts another instance of the fingerd program. Nasty attacker also recalls that using a single 0 instead of 127.0.0.1 makes no difference,^9.1 and putting two and two together, he executes

finger `perl -e 'print "\@0" x 100'`@victimhost

This will send a finger query to victimhost containing one hundred times the string @0. This causes fingerd to open up another connection to the local finger service, causing another daemon process to be started, and sending the string @0 repeated 99 times. So all in all, this will create at least 100 new processes on the victim server; maybe even twice as many if fingerd executes /usr/bin/finger for every forwarded query. On most systems, this used to be enough to bring the machine to a grinding halt.

There is an interesting twist to the story. Usually, the finger daemon is controlled by inetd. For every incoming TCP connection to port 79, inetd forks a new fingerd process - up to a certain limit. In its default configuration, inetd will not start more than 40 instances of any one service within 60 seconds. As many system administrators learned the hard way, this attack on fingerd will bring the machine to its knees before inetd reaches its limit.

Of course, this bug is ancient history. But when it was first reported to a public mailing list, many kids made it a sport to trash network servers running a vulnerable fingerd. Today, operating systems either ship with the finger service disabled altogether, or with a default configuration that disallows forwarding of requests.

Still, this example shows some characteristics of many remote denial of service attacks:

• By exhausting one resource, the entire system goes down the drain. In this case, the attacker creates a large number of processes which eat up all memory and CPU time.

  Therefore, this this group of attacks is also referred to as resource exhaustion attack. There are other types of denial of service attacks we will talk about later.

• Small investment, huge return. The amount of data the perpetrator transmitted was miniscule (a few hundred bytes only), so the attack could even be performed over a 9600 Baud modem. This is what makes these attacks so deadly.

• Resource consumption comes as a spike, rather than increasing continuously over a minute or two. This is what makes it difficult for the operating system to deal with. For instance, a slow increase in memory consumption over several minutes will usually cause increased swapping and make the system behave more sluggishly, but it won't cause any serious condition (at least, until you've managed to fill the entire swap space).

• The resource starvation will continue for a while after the attacker has stopped transmitting data. In the case of this @ attack, machines would remain wedged for half an hour or even longer; and some would even require a reboot to be useable again.

• This attack accomplishes nothing but causing the system administrator grief. In 90% of all cases, DoS attacks are simply digital vandalism. However, they can have more far-reaching consequences. For instance, a cracker planning ot attack your web server may decide to first take out the log server to which the web server transmits all logging information.