9 Evil Bash Commands Explained

I remember using and understanding a terminal for the first time: That feeling when you realize that you are able to reach every file, run every program and fully control the whole system by simply typing something into a black window. And I also remember the fear that came with it to make a mistake and lose or destroy something irrecoverably.

I'm not exactly a sysadmin, but over the years I worked with a lot of Linux/UNIX based systems and found myself more than once in a situation where I hesitated hitting the Enter key to rethink what I'm just about to execute.

In the following I want to share some commands you should not use at all or at least very carefully. If you're new to bash commands, I hope you can learn something new. If you're a bash pro, you can take this post as exercise to predict the result before reading the explanation.

Note: Some of these commands I learned myself the hard way, but most of them I picked up once in a while, i.e. in this old thread.

Before we start, the last warning:
⚠ Do not run any of these commands on a system you care about! ⚠

1. Destructive directory changing

I decided not to start with the classic rm -rf /* but with a variation of it:

alias cd='rm -rf'

💡 That's what happens

• alias declares a aliases/shortcuts for bash commands. The syntax is like alias alias_name="command_to_run"
• cd is the alias name and the same like the change directory command
• rm -rf is the command to run. This doesn't translate to "read mail, -realfast" rather than "remove the given directory with all its content without asking".

So if an evil person adds this alias to your open bash when you're afk and you want to cd through your file system, you will quickly notice a strange behavior...

Luckily alias will only be temporarily available throughout the current shell session, unless it's added to one of the files that are loaded on start of a terminal session, i.e. ~/.bashrc.

🛡 How to prevent possible damage

Well, simply don't add this alias and double-check the command, when adding a new alias. You can always check which aliases exist with the alias command and remove an alias with unalias alias_name.

To prevent deleting files unknowingly, you can add the following alias to your ~/.bashrc:

alias rm='rm -i'

This will make your bash always ask you before deleting something, even if the rm command is added as another alias.

* In case you didn't know: this command cannot be executed this simply anymore—an additional flag --no-preserve-root is required to execute it on the root directory.

2. Memory-eater

In case you doubt it, the following is a valid bash command:

:(){:|: &};:

💡 That's what happens

In short: Recursion without termination condition. A function is defined which is called :. It calls itself twice in its own definition. At the end of the command, the function is initially called. It becomes more clear, when we write it in separate lines and rename the function:

evil () {
  evil|evil &
}
evil

If this gets executed, it replicates itself quickly consuming all your memory and CPU resources (also known as fork bomb). It can freeze your whole system and is therefore an example of a denial-of-service attack. It's surprising how such an attack can be executed with a command of just 12 Bytes!

🛡 How to prevent possible damage

If you're using iterative or recursive bash functions, always double-check for proper termination condition and use a safe environment for testing purposes.

Since a fork bomb launches an unlimited number of processes, the only way to protect your system is limiting the number of processes a local user can run. You can do so by editing the /etc/security/limits.conf accordingly. A user could work with about 200-300 processes at the same time, so limiting to something like 2000 processes should shield your system from a fork bomb without limiting the corresponding user too much.

3. Zero memory

dd if=/dev/zero of=/dev/sda

💡 That's what happens

• dd is a command to copy data from one file or device to another
• if= specifies the source and /dev/zero is an unlimited source of zero bytes
• of= specifies the target and /dev/sda is a disk drive or volume

You see where this is going. It's an excellent way to erase the contents of a whole disk and a pretty quick way to lose a lot of data.

🛡 How to prevent possible damage

Unfortunately there is no -i flag as it is the case for rm, so my only advice is to double-check, if the devices you specified in your dd command are really the correct ones. Don't use the dd command at all, if it's to risky for you.

You can disable the whole dd command with the following alias:

alias dd='echo "no dd command available"'

If the dd command is now executed on your system, it only prints out no dd command available.

4. Zero recovery

The following variation of the above command is also possible:

for i in {1..10};do dd if=/dev/urandom of=/dev/sda;done

💡 That's what happens

This overrides the whole disk ten times with random bytes and minimizes the probability of recovering data even more.

🛡 How to prevent possible damage

Since this is also using the dd command, see the advices from the preceding section 4.

5. Uncommitted and lost

git reset --hard

💡 That's what happens

• git reset resets the current HEAD of a git repository to the last committed (or specified) state
• --hard resets the index and working tree. Any changes to tracked files in the working tree since the last commit are discarded.

In other words: it discards all uncommitted changes. Since these aren't tracked by git, there's no way to restore them.

🛡 How to prevent possible damage

Simply don't use the --hard flag. And if you have to: double-check if there are any local changes you want to keep before resetting it. I would recommend to do a hard reset only if the output of git status is empty or you're absolutely sure to wipe all uncommitted data.

6. Demolition by compression

tar -czvf /path/to/file archive.tgz
# instead of
tar -czvf archive.tgz /path/to/file

💡 That's what happens

• tar -czvf is the command to create a new archive, use gzip, show a verbose list of all files and use the given archive file
• archive.tgz the name of the archive file to create
• /path/to/file the path of the file to be compressed

The order of the files here is crucial. If the first file is the file you want to compress, it gets completely destroyed, because tar starts creating the archive by overwriting the first given file and realizes only afterwards, that the second given file doesn't exist. This is especially annoying if you wanted to make a backup of a file and used the wrong order of arguments...

🛡 How to prevent possible damage

Instead of grouping all flags together, you could separate the -f flag and use the longer version to remind yourself, which file the archive file is, e.g. like this:

tar -czv --file archive.tgz /path/to/file/to/compress

7. Too many rights

chmod -R 777 /
# instead of
chmod -R 777 ./

💡 That's what happens

• chmod -R applies file permissions recursively
• 777 permission mode to set (permit everything)
• ./ the directory or file which should be changed

If you don't pay attention which directory you want to target and accidentally take the root directory instead of the current directory, you will mess up all permissions of your whole system, making it impossible to use anymore.

🛡 How to prevent possible damage

To prevent the result of the typo above, you can add the following alias:

alias chmod='chmod --preserve-root'

This will always decline a recursive change on the root directory.

8. The root of all evil

The same applies to owner changes:

chown -R root:root /
# instead of
chown -R root:root ./

💡 That's what happens

• chown -R applies new owner recursively
• root:root the owner:group to set
• ./ the directory or file which should be changed

This will mess up all files in a similar way that you would most likely need to reinstall your system.

🛡 How to prevent possible damage

As we already did with chmod, you can add the following alias for chown too:

alias chown='chown --preserve-root'

This will also in this case always decline a recursive change on the root directory.

9. Encrypted and destroyed

fsck -y /dev/sda

💡 That's what happens

• fsck perform a filesystem check
• -y the flag to always attempt to fix any detected filesystem corruption automatically
• /dev/sda the volume to check

This is normally a good thing, except your volume is encrypted. In this case, the attempt of fsck fixing it would destroy it completely. A filesystem can only be checked after it is unlocked.

🛡 How to prevent possible damage

Only use the fsck command if you're absolutely sure, that you're using it on a normal, unencrypted volume. To prevent damage caused by an attempt of automatically fixing errors, don't use the -y flag at all.

---

Wrap it up

We saw that it's incredibly easy to destroy data or make a whole system unusable by typing a simple command.

I found that in the end the best protection is knowing what you type and double check for typos before executing something! Never just copy and paste code—that's especially true for bash commands! And: always keep a good set of backups.

Most of the commands above need root privileges to be executed. So always be careful what you do as root!

If you know another evil command, please share it with us in the comments below.

Disclaimer: I'm not responsible for any damage you do to your system by trying the above commands. Please use a safe environment like a virtual machine for testing. You have been warned.

---

Edited: 16th December 2019 (🛡 section for damage prevention)
Published: 10th December 2019
Cover Image: https://codepen.io/devmount/full/ExaPBra

Comments

[Evan Plaice]

[Andreas]

This is awesome 😂 Thanks for sharing!

[Jason C. McDonald]

Great to see these explained. You might put a warning at the top, though:

WARNING: DO NOT RUN ANY OF THESE COMMANDS ON A SYSTEM YOU CARE ABOUT!!!!

...just for the readers who might not have caught how evil "evil" really is.

[Andreas]

Thank you for this suggestions, I put that warning in! ⚠✔

[Michel Renaud]

Oh my... This is like a BOFH toolkit! (If you don't know what BOFH is, Google it. IT entertainment from the early to mid-90s).

[Andreas]

Well, yes you can see it this way 😅 but this post was completely meant for self protection not for making it easy for attackers... So I hope there are no BOFHs here... 🙊

[Michel Renaud]

A few of these scared me most in how easy it would be to make that mistake.

[Andreas]

Yes same here. That was one of the reasons to write this post. However I read that some of these depend on the Linux distribution, but I wouldn't count on that. I was really surprised to see, that chmod and chown both have a --preserve-root and --no-preserve-root flag to prevent misuse, but the default argument is --no-preserve-root! So if you run a command without a "preserve" option, it will default to "no preserve" mode and hence change permissions on a lot of files that shouldn't be changed.

[James]

I was thinking the same thing. Right up there with etherkillers.
If you don't know what an etherkiller is Google it. Basically an etherkiller is a modified ethernet cable that is hooked directly to a 110/220 power cord there are variations of that theme.

[Larry]

Wikipedia: The Bastard Operator From Hell (BOFH) is a fictional rogue computer operator who takes out his anger on users and others who pester him with their computer problems, uses his expertise against his enemies and manipulates his employer.

Hope this saves someone a couple of keystrokes.

[Michel Renaud]

The idea of googling it was for people to find the jokes, not the definition. ;)

[Michiel Hendriks]

It is better to use /dev/urandom
It is a PRNG and thus faster. /dev/random needs enough entropy otherwise it'll block.

[Andreas]

I see, thanks for your suggestions! I updated the post accordingly ☑

[thojest]

4) on steroids (much much faster than dev/urandom):

WARNING: THIS COMMAND WILL DELETE YOUR ENTIRE HARD DRIVE

openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt </dev/zero > /dev/sda1

we are using AES cipher of openssl in parallel mode to encrypt a stream of plain zeros with some random pw. this will look like random data. then we write to sda

[PJH]

"How to prevent possible damage"

Alias - prepend the command with a \

Presuming alias ls='ls --color=auto'
ls will show directories in colour
\ls will not.

Recursion - don't be root. Have user accounts limited in what resources they can use (CPU, disk space etc.)

dd - again, don't be root. Don't be in the disk group either.

chmod - don't be root.

[Jonathan H]

How is this supposed to be for self protection? This is like writing an article with step-by-step instructions on how to buy illegal goods and saying, "I'm telling you this for your own self-protection so that you don't buy illegal goods."

Like the fork bomb - nobody is going to accidentally run that, so there's no "protection" element to this knowledge. However, some irresponsible kid or disgruntled employee out there will probably use this for evil purposes....

[Andreas]

Thank you for posting your concerns. Let me explain, why your comparison doesn't work here. The bash is basically a very good thing (illegal goods are not) that gives you great power over your system. With that power comes great responsibility and I wanted to show, how a typo or copied code (like the fork bomb) can easily harm your system and lead to data loss, if you don't really understand what you're doing.

[Jonathan H]

Yes, bash is good but this is not an article in how to do good things with bash with a disclaimer to be careful. This is a collection of ready-to-use recipes for attacks.

With my comparison, I'm not saying the internet is evil and is only used for buying illegal goods. I'm saying that the internet CAN be used for evil purposes just like shells can be used for evil purposes. This article doesn't help understand how to properly use bash and in some cases it's not even specific to bash. All this article does is explain how to perform attacks.

[Andreas]

Thank you for your answer. I think we just have two different perspectives on this article here. My intention was to draw attention to how simple it is to make something wrong in bash. I can't change the fact that it's that simple. But I can spread awareness to help people don't make these mistakes. And given the positive comments on this article, I'm glad that it's seen this way.

And yes indeed, an evil person could use these commands to perform attacks. But it will always be the case that things with great impact are misused. How is it possible to spread awareness when you're not allowed to talk about it because somebody could misuse this information?

[Jonathan H]

Evil people probably won't bother to leave positive comments, so I wouldn't judge the impact of your article based on a few positive comments.

Articles that are truly designed for positive security impact usually focus on mitigation and prevention. Here you have almost none of that info. It's more like a "look at all the ways I know how to mess up a system - you can copy and paste these!"

It's great to discuss security risks, but if you don't talk about techniques for prevention, then it's really just a cookbook of evil recipes.

[Andreas]

Thanks again for your explanation. I agree with your last point, so I added a 🛡 section for each point explaining some ideas of prevention for the corresponding bash command.

[Kevin Ard]

I KNEW I'd see rm -rf on here, but the alias was a fun twist.
And you managed dd ♥️

Backstory: I see more than a few of these, but they'll show rimraf and skip over dd. This one... Yes. These are evil. You've earned your 🦄 lol

[Andreas]

Thanks 😊
Yes I thought rm -rf is very well known and therefore too boring 😅

[Django Janny]

alias dd='echo "no dd command available"'

This is not really safe... you still can call :

\dd if=/dev/zero of=/dev/sda

[Andreas]

Thank you for pointing out, I agree that dd can still be executed this way. Do you have another suggestion for a complete deactivation of this command?

[Django Janny]

Good question, my point was about learning dangerous command to use them with caution more than trying to avoid them with aliases and stuff like that... dd is a useful command if you know how to use it :)

[Andreas]

That's exactly what I was trying to show in this article. Most of the commands are very useful, it's just very easy to damage your system by mistake, so I tried to give some ideas of how to protect yourself from making these mistakes.

[Dave Cridland]

Ah. So rm -i is often seen as a solid protection, but it's really not.

rm asks in some cases anyway, particularly cases such as where you own the directory bu not the files within it. Those are outstanding cases, and using -i means these no longer stand out.

Secondly, I find it encourages people to use -f a lot, which is just bad behaviour outside of scripts. -f really shouldn't be used in an interactive shell - exceptional cases will no longer be asked about, and errors are lost.

Thirdly, try this, probably in an isolated environment like a docker container:

mkdir experimental-directory
cd experimental-directory
touch very-important-file
touch ./-f

# Now we want to delete files, but we'll rely on -i to avoid
# deleting the very important file.

rm -i *
ls

# Ooops...

I'll leave how to safely delete that -f file as an exercise for the reader...

[Andreas]

Wow, I didn't know that it's working like that! Thank you for pointing out, that -i is no solid protection.

[Mohammad Fazel]

Thank you for sharing horrible commands we should take care of...
About N5 if you have a good IDE like vscode you can get back to it and there is a way like ctrl+z.

However it will become so much difficult if there were lots of changes.

[Andreas]

You're welcome!
Yes you're right, with the help of external tools it might be possible to recover the data. I did this a few times with Sublime Text...

[Juan Ignacio Borda]

A coworker did an:
rm -rf /etc once...
Luckily we had an exact server with same config in the other rack an we restore it without service disruption
I wish a had a camera!

[Andreas]

Thank you for sharing this story. This emphasizes again how important backups are (in whatever form)!

[John shim]

just tried 1 command yesterday I'm commenting today to say that this post is savage hahaha

[Andreas]

😅 Which command did you try?

[Kenny Strawn]

rm -rf /sys/firmware/efi/efivars actually works on some systems with poorly implemented UEFI, and that command is something that even an attempted reinstallation won’t fix on the systems affected, since in those cases it bricks the motherboard.

[InsomniumBR]

You should cover the move command too. Applied to root makes a good damage!

[ehx-v1]

I wonder if 7. is actually that bad. If everyone can do everything everywhere, you (being a user among everyone) should have write access to everything as well, in particular all access properties, so you can set everything back to what it's supposed to be, although admittably you'll be busy for a while. The only risk is if you have some background process that messes with everything it gets access to, which is unlikely on a Linux and not sure if the command works under WSL.

For 8, I don't really see how it would hurt if root owns everything. Isn't that even a common pattern on certain server types?

I'm surprised that 9 is a thing, would've expected fsck to be smart enough to keep encryption apart from an actual mess (although arguably, it can be considered such in case of a ransomware attack, but that's nothing that can be fixed automatically anyway).