1 Understanding the Bash Fork Bomb
2 ================================
3 :author: Aaron Ball
4 :email: nullspoon@iohq.net
5 :revdate: November 12, 2015
6
7
8 == {doctitle}
9
10 I suspect that most Linux users, new and old, have at some point seen the
11 stereotypical fork bomb, whether they know what it was or not.
12
13 :(){ :|:& };:
14
15 A very cryptic statement that appears to have various forms of smiley faces in
16 it. But what does it do and how does it work?
17
18
19 == What is a fork bomb?
20
21 First, let's start by describing a fork. When a process creates another
22 process, that's called a process fork. For example, a program needs to read
23 data from two log files at the same time, so the main program process forks
24 two children processes, each to read data from the log file into memory. While
25 those two processes are running, the program consistes of three running
26 processes: the parent and two children.
27
28 To see this in action, a fun command to run is
29
30 ps -ef --forest
31
32 That command will show you a graphical representation of parent processes and
33 their children (and their children's children and so on).
34
35
36 A fork bomb is is a process that forks off children processes, each of which
37 forks off its own children processes. For example, assuming each process
38 creates two, the parent process would create two children processes, each of
39 which creates two more. The result becomes 1 -> 2 -> 4 -> 16 -> 256 -> 65536.
40
41 The key concept that makes a fork bomb work [so deviously] is that the parent
42 process of any child processes won't exit until the children exit. In the case
43 of a fork bomb, the task of a child process is to create more children
44 processes, thus they never exit because there is no terminus for process
45 creation.
46
47 To summarize, a fork bomb could fill up a system's process table very fast. In
48 the example where we created 2 new children for each process, it took 6 steps
49 before we hit 65536 processes, which would crash many systems.
50
51
52 == How does this fork bomb work?
53
54
55 To better understand the stereotypical bash forkbomb, let's expand it into more
56 human-readable code. First, the original forkbomb for easy no-scroll reference.
57
58 :(){ :|:& };:
59
60 Now, let's break the function apart. In bash, there are two ways to define a
61 function
62
63 function some_name {
64 # Do stuff here
65 }
66
67 and...
68
69 some_name() {
70 }
71
72 The forkbomb mentioned at the beginning of this post uses the second function
73 syntax. As you can see, using that syntax, it creates a function called *:*.
74 Now, let's expand this into a much less compressed format now, by using the
75 first syntax, breaking it into multiple lines, and renaming the function from
76 *:* to *foo*
77
78 function foo {
79 foo|foo&
80 }
81 foo
82
83
84 Now that's much easier to understand. It's fairly clear now that this creates
85 a function called foo that calls foo, piping the output to another call of foo
86 that's backgrounded so it can continue (the &), then finishes the function
87 definition and calls foo to start things off.
88
89 As mentioned, once the function is called, it calls _foo|foo&_, which
90 basically executes foo, piping the function's output (nothing) to a new
91 instance of the foo function, and backgrounding that process. However, within
92 the foo function, it calls foo again, which inside, has two more calls to foo,
93 etc. Effectively, it recursively creates two children functions that never
94 close because they each create two children functions that never close because
95 they each create two children functions... Get the idea?
96
97 Ironically enough, despite how impacting this function can be, it actually does
98 relatively little work except to create new instances of the function. Kind of
99 devious that a function that does no real processing can bury a system with
100 load.
101
102
103 [role="datelastedit"]
104 Last edited: {revdate}
105
106 // vim: set syntax=asciidoc:
|
