Hacker News new | comments | ask | show | jobs | submit login
Rm -rf remains
352 points by mmastrac on June 14, 2014 | hide | past | web | favorite | 45 comments



Related but fun commands to try along same vane (as root).

(WARNING: These make a mess don't do this on a system you care about)

(NOTE: Spaces matter here watch if you cut-paste)

    yes > /dev/mem
    dd if=/dev/urandom of=$(mount|sed -n '/\/ /s/ .*//p')
    rm -fr /lib /usr/lib
    rm /etc/passwd && init 6
In the good 'ole days me and a friend of mine would boot a Xenix system from an 8" floppy that was designed to bring up console and tty1 with a bash prompt. The goal was to see who could crash the system the fastest.. Then we'd copy the disk, reboot and do it again.. The number one rule was you couldn't use the same one-liner in the next round so each round got more and more convoluted.


I did the third one (mv, not rm) to a system I cared about with a full hard disk early in my linux tutelage.

Educational day.


This is a nice exploration of what's built into the bash shell. Handy not just for when you rm -rf / , but also for when you suddenly find yourself lacking in usable tools. For instance, I've had an upgrade break the dynamic linker (/lib/ld-linux.so.2 or /lib64/ld-linux-x86-64.so.2), and suddenly no dynamically linked program runs.

However, the solution given here assumes you have a bash compiled with support for /dev/tcp. You can, instead, paste the necessary executables directly over the existing connection to the system, encoded to survive that transport.


This is basically a bootstrapping problem and turns out to rest on these critical functions:

- being able to create a file containing arbitrary data

- being able to make a file executable

- being able to execute a file

Would the same be possible if your shell was not bash but one with fewer features, like e.g. POSIX sh? That doesn't even require echo to be a builtin (it only has the 3rd function above), so it might be a dead end, but maybe there's some other way...


Alternatively, I think it might be possible if you can cause arbitrary interrupts to the operating system and control some registers and perhaps the stack as well. Depending on the shell, you might be able to do this; you certainly don't need the standard command-line tools for chmod and cat, because those are just small programs that pass through to actual system calls:

http://docs.cs.up.ac.za/programming/asm/derick_tut/syscalls....


How are you going to cause arbitrary interrupts from the shell?


The classic version of it:

http://lug.wsu.edu/node/414


I've had very similar experience. I believe it was Oracle 7 and one smart guy tried to install it into the root folder. The only problem was that the install script did 'rm -rf $DESTFOLDER' at the beginning. Luckily for us, the script actually printed the commands on the console and the guy quickly realized what is about to happen. He aborted the install script but by the time /etc and quite a few other things were gone.

It was a Sun OS 5.1 I believe on a pretty big box (for its time) with A LOT of user data. We recovered it using roughly the same steps. We didn't need to write in assembler though since we've had Sun compiler tool chain in /opt that survived. At the end, we used a modem to connect the damaged box to another one with a tape backup. It took about 12 hours to copy the data over.


On Macs, /Applications is probably the first to go. I stopped an rm -rf /* (intended .*) inside /Applications/Adium.app. I'm really glad I wasn't using a SSD!! Adium itself started acting very odd. One of the many issues was that sending a message to a specific person actually sent the message to a group chat. I was lucky to figure that one out before I cursed out the group chat while describing my stupidity.


Thanks for that. I had this strong feeling that this was very much basically the same as something (classic) that I had read before.


Mildly interesting: CoreOS is shooting for `rm -rf /` being safe and similar to a "factory reset" on your phone. Here are the results on vagrant after rebooting a machine where `rm -rf /` was done: http://i.imgur.com/VMuPkf3.png


This article feels like a "Minecraft" in desolated Linux system.


I was thinking more of a post-apocalyptic sci-fi story.

> We lost everything in the Big War. Luckily our last supplies of Bash built-ins were left intact. If we pool our resources and use our remaining executable bits wisely, we might just last through the nuclear winter.


That was more or less the premise behind 0x10c http://en.wikipedia.org/wiki/0x10c


If somebody actually made something like that it'd make debugging even funner than it already is.


Reminds me of the Doom process manager: http://psdoom.sourceforge.net/


About 25 years ago I saw somebody do a "chmod a-rwx ." as root, at root on an SunOs box. Recovering from that was almost entertaining ;-)


A few years ago I changed over from a Dell PC Keyboard to an Apple keyboard.

I had to delete some files in a temp folder and typed the command as I was always used to, and pressed enter.

Immediately realised something was wrong and then saw the "*" replaced with a "/". Did not have a fun afternoon.

http://i.imgur.com/4k4SOpF.jpg


My worst has been accidentally removing zip - back in my Slackware days IIRC. I was trying to upgrade and so I removed the old one and then went to install the new one and couldn't install it again as the packager used zip and all the downloads I could find were tar.gz (or tar.bz2 or whatever).

That was the first, and last time I think, that I used cpio. Phew.


But the superuser privileges should have overridden such directory permissions, even 25 years ago....


Yes, but if you can't run the chmod binary...


No, root can still run chmod, because its superuser privileges override the new restrictive directory perms. That was my point.

Maybe the original problem was actually "chmod a-rwx /bin/chmod" ... That would mean even the superuser couldn't execute /bin/chmod anymore, so you'd have to do something more creative to reset the executable bit on /bin/chmod. Like compile a C program that calls the chmod system call, or:

  mv /bin/chmod /bin/chmod.orig
  cp -p /bin/ls /bin/chmod
  cp /bin/chmod.orig /bin/chmod


> Like compile a C program that calls the chmod system call

The compiler wouldn't be executable anymore either


Yes, it would. Like he said, you can still run it unless you specifically removed its permissions.


The explanation for what made him type that is what interests me. It would be like accidentally cutting your left hand clean off with a steak knife while you were eating dinner.


My bash is set to use vim bindings (set -o vi) and I constantly loop through commands. I am guilty of doing this while sleepy and sometimes I think I have cd to another directory when in fact I have not. I rm-ed (too) many things that way.


I gave the vi mode a very short try, but it doesn't seem to make as much sense in a shell. If it has you accidentally deleting things, you might want to ask how much is it really worth. In vim you can undo.


One can use the shared library loader to invoke binaries that do not have executable bit set, comes in handy once in a while.

  $ cp /bin/chmod .
  $ chmod -x ./chmod
  $ /lib/ld-2.19.so ./chmod
  ./chmod: missing operand
  Try './chmod --help' for more information.


My worst has been accidentally removing zip - back in my Slackware days IIRC. I was trying to upgrade and so I removed the old one and then went to install the new one and couldn't install it again as the packager used zip and all the downloads I could find were tar.gz (or tar.bz2 or whatever).

That was the first, and last time I think, that I used cpio.


Oh, the pain! I remember doing that 25 years ago too, ouch.


That was a really fun read. I had no idea that bash supported loading plugins out of shared libraries with the "enable" command.


I'm trying to work out how enable is useful over dropping an executable in /bin or ~/bin (not in this story, but in general)

It's definitely a nice trick, though.

Edit: http://cfajohnson.com/shell/articles/dynamically-loadable/


bash enable sounds like a potential attack vector for executing code on a filesystem that would otherwise not allow it.


Thanks for the nice description!

For my small Linux emulator I put the link in the Wiki after "Destroy the system" :)

https://github.com/s-macke/jor1k/wiki/Explore-the-emulator#r...

The system runs already on Busybox, so the whole binary is in RAM. Is there a way to restore the binary from /proc ? Or to restore the symlinks and maybe link them to /proc/self/exe or so?



I lol'd on an attempt to find the executables to overwrite. It does make sense, though the applicable files are already gone.


Shouldn't you still be able to directly invoke ld-linux.so to load the ELF binary, even if it's marked as non-executable?


That won't help when it has been deleted :)


There may be an obvious reason, but if using another machine is fair game as he did in one of the examples, then why did OP not just copy ls/chmod/etc from another machine to poke around?


How are you proposing he copy it from another machine? There's no file transfer program, client or server, remaining. Nor is there a way to mount an external filesystem. The whole point of the exercise is to bootstrap up from the few remaining resources to the point where you can "just" copy stuff in from another machine.


If the ssh connection remains (it is what he is using to poke around afterall), you can tunnel through the active connection without having to create a new one http://unix.stackexchange.com/questions/2857/ssh-easily-copy...


Yeah, which is why probably the first thing I would have copied over would not have been busybox, but probably rz.


Already posted → https://hn.algolia.com/?q=lambdaosp

It would have make more sense to at least change the title to make it more explicit.


Reposts are fine when an item hasn't had significant attention within about the last year. The previous post had 10 points, but 0 comments, so this repost probably doesn't count as a dupe.





Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: