From Wikipedia:
The fork bomb is a form of denial of service attack against a computer system that implements the fork operation, or equivalent functionality whereby a running process can create another running process. It is considered a wabbit as fork bomb programs typically do not spread as worms or viruses. It relies on the assumption that the number of programs and processes which may be simultaneously executed on a computer has a limit.
Yes, the command “:(){ :|:& };:” looks like a bunch of rabid smileys, but in fact is a dangerous command that could leave your Linux system unusable until rebooted. The command essentially creates a DoS attack on the system by spawning a large number of processes and very quickly taking all available resources and process slots. This is especially important on multiuser systems like terminal servers, web servers, etc.
The jargon file also defines fork bomb.
Linux is not the only vulnerable OS, but lets focus on the bash command structure for now and I will fill you in on ways to prevent your system from being vulnerable from this command and catching users who attempt to start the fork bomb.
Essentially the code says:
Bomb the bombs while I drop bombs with even more bombs.
But how do I prevent the fork bomb?
Linux has a handy pam_limits module that can limit the amount of resources any one group or user can take. The configuration is stored in the /etc/security/limits.conf file. This will restrict the user or group from spawning more processes than defined in the configuration.
NOTE: This requires that you have the pam_limits module installed.
Example configuration:
user hard nproc 300
@group hard nproc 300
Replace ‘user’ with usernames and replace ‘@group’ with group names. You might have to play around with the settings and see what works best for your environment and available resources.
OK, but someone is dropping the fork bomb and I can’t tell who it is!
You could simply look in their ~/.bash_history and see, but that isn’t to say they haven’t deleted it out of the file.
The Linux kernel patch grsecurity could be another solution. I don’t have much experience with the patch so I cannot go into great detail, but the grsecurity forum has a bit of information on the issue.
If you have not setup ways to protect your mutliuser system from the fork bomb, it just might leave you dropping the F bomb. We wouldn’t want to hear any system administrator saying that, would we?
Know any other ways to create the fork bomb? Leave a suggestion in the comments.