Would globally aliasing the fork bomb prevent its execution?

If you were to globally set

alias ':():& ;:'='echo fork bomb averted'


would that be an effective security strategy to avoid the Bash fork bomb execution or would there still be a way to execute it?

I suppose the question cashes out to: is there a way to execute a command when it's aliased to something else?

a() a;a

4 Answers
4

The two, no, three, ... Amongst the main obstacles to that are:

It's not a valid name for an alias. Bash's online manual:

The characters ... and any of the shell metacharacters or quoting characters listed above may not appear in an alias name.

(, ), &, | and whitespace are out in Bash 4.4.

(

)

&

|

That particular string is not the only way to write a fork bomb in the shell, just famous because it looks obscure. For example, there's no need to call the function : instead of something actually composed of letters.

:

If you could set the alias, the user could unset the alias, circumvent it by escaping the alias name on the command line, or disable aliases altogether, possibly by running the function in a script (Bash doesn't expand aliases in noninteractive shells).

Even if the shell is restricted enough to stop all versions of a fork bomb, a general purpose system will have other programmable utilities that can recurse and fork off subprocesses. Got Perl or a C compiler? Easy enough. Even awk could probably do it. Even if you don't have those installed, you'll also need to stop the user from bringing in compiled binaries from outside the system, or running /bin/sh which probably needs to be a fully operational shell for the rest of the system to function.

/bin/sh

Just use ulimit -u (i.e. RLIMIT_NPROC) or equivalent to restrict the number of processes a user can start. On most Linux systems there's pam_limits that can set the process count limit before any commands chosen by the user are started.

ulimit -u

RLIMIT_NPROC

pam_limits

Something like this in /etc/security/limits.conf would put a hard limit of 50 processes to all users:

/etc/security/limits.conf

* hard nproc 50


_{(Stephen Kitt already mentioned point 1, Jeff Schaller mentioned 2 and 3.)}

&

&

No. There are just too many ways to write a fork-bomb.

The evil fork-bomb writer will just try again with a different function name. Or other alterations until his fork-bomb succeeds.

The inadvertent fork-bomb writer won't produce the canonical fork-bomb in the first place.

It's actually rather easy to become an inadvertent fork-bomb writer yourself. For instance, you could just use recursive make with an external, unchecked cd, combining it with the -j option and non-existing subdirectories -- a real example I've stumbled upon once.

make

cd

-j

You cannot safeguard against all possibilities, and most certainly not against a determined attacker. All you will achieve is to increase the complexity of your system.

You can’t alias a fork bomb, because it’s not a valid alias name:

$ alias ':():& ;:'='echo fork bomb averted'
bash: alias: `:():& ;:': invalid alias name


The characters ‘/’, ‘$’, ‘`’, ‘=’ and any of the shell metacharacters or quoting characters listed above may not appear in an alias name.

Some shells don’t check alias names when they’re declared, but when interpreting commands, and skip the invalid name then. A fork bomb will always include &, which can’t be included in a valid alias name, so protecting yourself in this way isn’t possible.

&

dash

bosh

Twice, no.

That's not the only way to write a fork-bomb.

There's also several ways to execute "a command" when there's an alias:

command the-command
the-command


Example:

$ alias ls=not-really-ls
$ ls
-bash: not-really-ls: command not found
$ ls
jeff.html output.png
$ command ls
jeff.html output.png


ls

output.png

command ls

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.