Tecnología, Internet y juegos
260 meneos
2392 clics
Ejecutar el comando “rm -rf /” en un Linux arrancado con UEFI puede dejar inservible el equipo de forma permanente [ENG]

Ejecutar el comando “rm -rf /” en un Linux arrancado con UEFI puede dejar inservible el equipo de forma permanente [ENG]

Ejecutar el comando “rm -rf /” en un Linux que use UEFI puede dejar inservible el equipo de forma permanente. Cabe decir que borrar de forma recursiva todos los archivos y directorios no es recomendable. Pero si se hace en un sistema en el que la variables de EFI están montadas en modo lectura-escritura en “/sys”, puede llevar a inutilizar la implementación de UEFI, lo que llevaría a tener un sistema completamente inservible. [El error se reporta en el GitHub de ‘systemd’: github.com/systemd/systemd/issues/2402 ]

| etiquetas: rm -rf / , comando , efi , uefi , efivars , dejar inservible , linux
116 144 6 K 391
116 144 6 K 391
Comentarios destacados:                                  
#12 #9 "La programación es una carrera entre los desarrolladores, intentando construir mayores y mejores programas a prueba de idiotas, y el universo, intentando producir mayores y mejores idiotas. Por ahora va ganando el Universo"
-- Rich Cook
«123
  1. Menos mal que en Windows eso no se puede hacer
  2. Pues menos mal que han avisado. Iba a ejecutarlo en cuanto acabase lo que estoy haciendo
  3. #1 Siempre tiene que haber un comentarista de la noticia sin haberla leído, en especial donde dice que se puede hacer lo mismo con cerca de 20 líneas de código en Windows.

    Premio :calzador:
  4. #3 es que “rm -rf /” me puede salir de casualidad, pero 20 líneas ya sería mucha casualidad :troll:

    como saltáis algunos....
  5. #2 Lamentablemente conozco un caso en el cual un programador que usaba linux estaba medio dormido, fue a hacer un rm -rf /[presionar tab para poner el unico archivo dentro de la carpeta]

    Si, no tenia ni que poner el /, ni tampoco le dio al tab.

    Y todo que si que si que si...
  6. #1 Sólo te quedan 999.999 formas de joder un Windows
  7. #4 faltaría un sudo delante o hacerlo como root. Hay millones de combinaciones posibles en el teclado, dudo que justo "rm -fr /" sea la que te vaya a salir, de hecho es más probable que te atropelle un coche de que te salga justo esa combinación de casualidad. Si te atropella un coche estos días no me lo eches en cara... :troll:
  8. #7 cosas más raras he visto :-D
  9. ¿Cuántos seres humanos, en su sano juicio, ejecutarían "rm -rf /"?

    Edit: Perdón "sudo rm -rf /"
  10. #5 Yo conozco a uno que como administrador revocó los privilegios de una base de datos. Sí, también los suyos propios. Menudo merluzo.

    También conozco a otro que con un editor de disco, cambió en el sector de arranque la palaba "WINDOWS" por su nombre. Tuvo que sacar el disco duro y ponerlo en otro equipo para volver a ponerlo bien.

    Así que, sí, me lo creo.
  11. #5 Me parece recordar que alguna aplicación tuvo un bug en el que ejecutaba el comando "rm -rf /+ una variable que contiene la ruta del fichero" sin comprobar si la variable estaba o no vacía, con lo cual si se ejecutaba como root te podía causar un estropicio importante. En ese caso puede ser un descuido comprensible. Pero escribir en línea de comandos rm -rf /loquesea no se me ocurre ni harto de vino
  12. #9 "La programación es una carrera entre los desarrolladores, intentando construir mayores y mejores programas a prueba de idiotas, y el universo, intentando producir mayores y mejores idiotas. Por ahora va ganando el Universo"
    -- Rich Cook
  13. Otra nueva prueba de por qué un programa monolítico que gestiona todo no es buena idea?
  14. A veces pasa que vas a poner "aysi .ed &" y confundes la posición de las manos y te sale "sudo rm -rf /"
    A mi me pasó una vez estudiando mecanografía en la consola.
  15. #5 como intrépido linuxero... algo falla en esa historia...
  16. #10 baneé mi propia IP de un servidor y después no podía acceder. :palm:
  17. #18 palabra de Cook
  18. #11 Fue el script que lanzaba Steam.
    news.softpedia.com/news/Steam-for-Linux-Can-Delete-Home-Folder-with-rm

    De todas formas casi todas estas cosas pasan por no trabajar con linux (o cualquier Unix) como debe trabajarse. Es decir, importándote todo una mierda y sin tomar precauciones ni leer lo que sale por pantalla. Más o menos es como conducir un coche y pensar que puedes prepararte un chocolate con churros porque tienes las rodillas libres para mover el volante.
  19. #15 Y cosas peores que pasan. El otro día venía a meneame y acabé en una página de sado y al ir a retroceder en el historial me metí en una videosala, luego explicaselo a la parienta claro.
  20. #10 "Yo conozco a uno que como administrador revocó los privilegios de una base de datos. Sí, también los suyos propios. Menudo merluzo."

    Eso nos pasa a todos. A todos. Y mejor antes que después.
  21. Esto nunca me pasará con mi olivetti. Claro,que cada vez es más difícil encontrar carretes de cinta de color rojo .
  22. #17: Eso es peor que un "delete from" terminando con toda vida. :-S
  23. #2 Pues yo lo acabo de probar y no pasa nad
  24. Supongo que no hace falta hacer rm -rf / sino que con un rm -rf /sys bastaría para joder la UEFI
    Imagina ahora que eres "creativo" y tienes un directorio llamado /sus/ y te equivocas al teclear la orden para borrarlo porque la "u" y la "y" estan juntas en el QWERTY de mierda...
  25. #23 Se refiere a systemd.

    Pero en un mundo en el que la última moda son containers corriendo microservicios, irremediablemente vamos de cabeza a que una mierda como systemd se implemente en todas partes, para que así en el microcontainer todo se pueda gestionar fácilmente.

    Y al que todavía ande con servidores, pues a ese que le den morcilla (o que se pase a OpenBSD, que es un buen momento).
  26. ¿Pero alguien lo ha comprobado? ¿Es de fiar la fuente? :-P
  27. #5 Fue famosa en un repositorio de github una actualizacion en la que un a rm -rf /usr/appxxx/appdata se le cayo un espacio despues de la primera barra. Le inundaron la linea a base de memes. "No suelo borrar todo el disco, pero cuando quiero hacerlo, actualizo appxxx"
  28. Oj que interesante. Necesitaba saberlo para seguir viviendo.
  29. #3 En Windows también se puede arruinar el sistema si le metes fuego o lo golpeas repetidamente con un martillo grande. Y NO HAY PARCHE.
  30. #3 ¿cuánto crees que tardará en aparecer un virus para windows que amenace con inutilizar tu PC si no pagas un rescate?
  31. ¿También si lo hago dentro de una máquina virtual?  media
  32. #12 buenísimo!! xD
  33. #30 Voy a probarlo. Te digo ahora :shit:
  34. y los del PP, a martillazos, buag pardillos
  35. yo he visto en una empresa los de sistema hacer un script para borrar una aplicación en Windows con un bat que se cepillo el system32 de los equipos, el script si tenias el directorio de la aplicación no había problemas.... perooooo si no existía devolvía de variable de ruta c:windowssystem32 ... con dos cojones tumbaron las maquinas de los jefes de departamento que eran los que debían de tener la aplicación y no la tenían. {0x1f602} {0x1f602} {0x1f602} {0x1f602}
  36. #1 Es conveniente leerse las noticias: "Matthew says with about 20 lines of code on Windows, you can cause the same havoc."
  37. Y por eso es malo estar logueado como root todo el rato. Ajo y agua.
  38. #29 Creo que la nueva versión de Slackware todavía no implementa systemd. Pero en cuanto a Patrik le de por meterlo, me cambio a FreeBSD.
  39. #9 en el pc d un colega... Algunos..
  40. #9 recuerdo ciertos drivers alternativos de cierto fabricante que por un bug el script ponia rf -rf /dev /algo en su proceso de instalacion.
  41. #8 #7 Puedo decir que hace ya años fui uno de esos [des|a]graciado, menos mal que fue probando una distro :palm:.
  42. Vamos, que nadie lo ha probado:

    # rm -rf /
    rm: it is dangerous to operate recursively on ‘/’
    rm: use --no-preserve-root to override this failsafe
  43. Pues a pesar de que me consta el prestigio de Phoronix, no me creo esta noticia. A ver, si borro los archivos de la UEFI sólo tengo arrancar de otro disco duro, en el peor de los casos previamente desconectando el que he borrado con mis manos de árbol. ¿Me equivoco?
  44. #9 Te podría contar el caso de un alguien que ejecutó "rm -Rf . /path_irrelevante" y se dió cuenta, algo después de confirmar y volver de fumar un cigarro, que los espacios en blanco también cuentan.
  45. #25 Activé el SSH sin password... y tenía una errata en el authorized_keys...
  46. #12 El universo ha descubierto la táctica perfecta: Meter algunos de sus mejores idiotas como gerentes de proyectos de desarrollo. :->
  47. #6 Joder el Windows es una cosa, si jodes la UEFI el HW sirve como posapapeles.
  48. A ver, el articulo puede llevar a confusión. Me explico:
    La UEFI no vive en el disco duro junto al sistema operativo, sino en memoria ROM solo de lectura, y la configuración y actualizaciones de esta, se almacenan en la memoria CMOS, que va alimentada por la pila de la placa base.

    Esto que quiere decir? Que te puedes cargar la parte del sistema operativo encargada de arrancar desde UEFI, y te veras obligado a reinstalar el sistema operativo, pero en ningún caso supone un "perma-brick" como ellos dicen.

    El problema puede ser en todo caso, que algún fabricante no monte la UEFI sobre memoria ROM, y permita sobrescribirla, pero esto no es lo habitual.
  49. #10 Yo hace días con herramienta de hp para crear pens bootables de dos me cepille dos particiones en un disco de 500G 10 horas de recuperación..
  50. #43 Oye colega, ¿me dejas un momento tu PC con Linux que pruebe una cosa?, ¡verás qué risas! (al menos por mi parte, cabrón roba novias)

    ¿te refieres a algo así?
  51. #25 Mención obligatoria (no te olvides de poner el where en el delete from): www.youtube.com/watch?v=i_cVJgIz_Cs
  52. #34 48 horas 1000€ + 5 % beneficios.
  53. #34 Ya los hay.
  54. #22 La proxima vez que pruebe un DELETE DATABASE y ya veras que risas!
  55. #7 Al azar no, pero cosas como:
    rm -rf / tmp
    Eso si puede pasar, solo es poner un espacio por error donde no debías. Combinaciones donde puedes borrar / o * (estando en /) cambiando solo un espacio hay a patadas

    Todavía hace no mucho lance un rm -rf que por error se comia todo *
    (Algo como rm -rf ~/folder/anotherFolder/* me salio rm -rf ~/folder/anotherFolder/ *). Vale que no era root, pero aun asi, como root o sudo si que lanzas rm -rf a veces
  56. eso debe ser equivalente a en su dia con Mac OS pre-X (hasta el sistema 9) arrastrar a la papelera la carpeta System.
    El cachondo te dejaba, y no pasaba nada, todo seguía funcionanod. Hasta que reiniciabas y te decía que no encontraba al sistema :-D
  57. #45 En realidad eso solo se carga el disco, esto te deja la placa frita
  58. #54 No hay confusión: "On UEFI distributions by default where EFI variables are accessible via /sys".

    Si borras todo el sistema de archivos afecta al directorio /sys/firmware/efi/efivars

    De todas formas, no se puede hacer un rm -rf / desde hace mucho tiempo, porque rm da error, como ha dicho #47. Pero el problema está ahí, lo de menos es como se haga.
  59. #45 que se lo digan a Barcenas. Venga ya me lo pongo yo :calzador:
  60. #48 Creo que si. Cuando se refieren a borrar archivos de UEFI, no se refieren a los archivos que normalmente tienes en el disco duro para arrancar UEFI, sino a archivos que directamente se almacenan dentro de la implementación UEFI de tu placa base
  61. #33 Hombre, digo yo que un par de curitas sana y una tirita lo arreglaran no? :shit:
  62. #47 Es cierto, positivo para ti pero, ¿podrías probar?

    $ rm -rf /*

    Y ya me cuentas :troll:
  63. #53 Ok. Me documentaré
  64. #47 Es que "no-preserve-root" es demasiado esotérico, deberían hacer como hdparm y poner algo como "please-destroy-my-drive" cuando vas a actualizar el firmware de un disco que queda mucho más claro, a la par que educado.
  65. El año de Linux en la papelera :troll:
  66. #1 Estamos hablando de que el problema no es que se borre el sistema de ficheros, sino que al montarse el firmware de la UEFI en dicho sistema de ficheros y al necesitar permisos de escritura si por casualidad se borra el sistema de ficheros, se destroza todo el ordenador. Y esto es así tanto en linux como en windows. Y no lo digo yo, lo dice Matthew Garret, uno de los desarrolladores que lidia con UEFI en systemd:

    "Matthew says with about 20 lines of code on Windows, you can cause the same havoc."
  67. #57 JAJAJA ¿De dónde has sacado eso?
  68. #13 Es unix el que monta dispositivos como si fueran ficheros, de ahí que borrando el sistema de ficheros termines borrando un firmware con permisos de escritura como es el UEFI. Y eso #23 #35, es independiente del tipo de unix, o la políticas que use.
  69. #42 ¿y eso por qué? (o sea, detállame todas esas cosas que hacen tan malo systemd y por qué matan el espíritu de slackware, por favor)
  70. A mi esto me parece más un problema de linux, por la facilidad de que se utilice mal ese comando que desde windows. Es obvio que si puedes modificar cosas del ordenador siempre puedes cargarte algo, pero esa funcionalidad "inesperada" me parece más probable en linux.
  71. #4 Si quieres borrar todo lo que hay en el directorio actual... ¿que haces?

    rm -rf ./

    Imagínate que se te olvida o te falla el punto.
  72. #62 No sé porque me imagine que alguien seguro que se planteo si sería mejor dejar que el usuario lo moviera, y si no estaba, buscarlo en la papelera...
  73. #7 hay muchos manuales en los que se empieza:

    "sudo su -"

    y a continuación, todos los comandos.
  74. #54 Al estar la memoria mapeada en el sistema de ficheros, si sobreescribes el fichero que la mapea, sobreescribes la memoria. Y a tomar por saco todo si no puedes forzarla durante el arranque a cargar los valores de fábrica o algo similar. Y el caso es que ciertas aplicaciones tienen permiso de escritura (lo de montarla como sólo lectura se ha descartado porque por lo visto se cargaría el funcionamiento de muchas cosas, si no realmente no habría problema).
  75. no lo creo
  76. #29 ¿Y la solución es seguir usando SysVinit u otro init de los que fueron diseñados cuando las máquinas no eran ni siquiera multinúcleo, que encima esté basado en scripts, en una época donde ahora conseguir procesadores de varios núcleos está al alcance de todos?

    Yo ya trabajo con Debian 8 en servidores y usando gestión de servicios al 100% usando systemd y sigo sin comprender el odio que le teneis algunos. De hecho ahora mismo facilita mucho más el control del sistema aparte de que ahora está integrado con el kernel. El journal que tiene es simplemente fantástico y no el síndrome de diógenes que generaba SysVinit que te volvias hasta loco.
  77. alias rm='rm --preserve-root'
  78. #77 Hay algo peor, y es que se te cuele un espacio entre el punto y la barra (me pasó):

    rm -rf . /

    eso también funciona... pero no borra sólo el directorio actual...
  79. #75 Systemd al estar integrado con el kernel, tenemos que depender más de él, lo que viene a ser una reducción de libertad ya que acapara todo. Por otro lado usa otra sintaxis alejada del shell script y eso te obliga a que ahora tengas que aprender el funcionamiento de los "unit" para que puedas agregar por tu cuenta servicios en systemd.

    Más o menos por ahí van las mayores quejas sobre la implementación de systemd.
  80. Hace una semana hice casi lo mismo en un servidor Ubuntu 14.04 LTS que dejaba atrás por migración a otro:
    rm -rf *
    Ejecutado como root y desde el raíz.

    Lo gracioso es que el terminal SSH siguió funcionando, aunque me quedé casi sin comandos ni para hacer el shutdown final. Si luego arrancaba o no, ya sería cosa de preguntarle al siguiente usuario...

    En otro Ubuntu 14.04:

    root@archivos:~# ls -lisa /sys
    total 4
    1 0 dr-xr-xr-x 13 root root 0 feb 1 20:08 .
    2 4 drwxr-xr-x 22 root root 4096 ene 24 06:09 ..

    Ta vez no es UEFI, pero /sys (.) está sin permisos W y en /etc/fstab no figura como punto de montaje nada relacionado, puede que haya algo que desconozco al respecto.
  81. #57 Hasta he hecho imágenes de fractales relacionadas con esa canción. también la traduje al inglés cuando me di cuenta que nadie antes lo había hecho...
  82. #76 Ciertamente, es mas facil que ocurra accidentalmente en linux. El principal problema es que aunque prácticamente todo el mundo entiende que rm -rf / va a borrar todos los ficheros de tu disco duro, es que muy poca gente se da cuenta que puede borrar información fuera de tu disco duro. No tienes más que leer este hilo para darte cuenta que mucha gente asume que con reinstalar el sistema el problema se arregla

    Incluso con el warning que comenta #47, puedo tener un motivo legitimo para querer borrar todos los ficheros de / pero no soy consciente que borrando /sys puedo dañar la placa. Y hay formas de lanzar esto sin que aparezca el warning:

    Pongamos este ejemplo:
    mkdir /tmp/chroot/sys
    mount -o bind /sys /tmp/chroot/sys (o cualquier otra variante para replicar sys para el chroot)
    chroot /tmp/chroot
    ... do stuff
    exit (exit the chroot)
    rm -rf /tmp/chroot

    Esto parece seguro, pero si no me equivoco, podríamos acabar dañando la placa (igual no pasa al borrar los ficheros de /tmp/chroot/sys, pero al ser un bind, imagino que si
  83. #62 prueba a borrar mp3 mientras los escuchas. En Ubuntu al menos, si tienes el archivo (ogg uso yo) abierto lo puedes seguir escuchando. Creo que tiene que ver con que abre los archivos en alguna memoria intermedia. Por ejemplo, cuando borras un exe, da igual que esté ejecutándose con WINE, te deja borrarlo y de paso te evita el "este archivo lo está usando un programa, de verdad quiere borrarlo" Sí. "¿De verdad?" Sí. "¿Seguro?". Que sí, narices. (vida real en güindous).
  84. #76 en Güindouns también hay una terminal que necesitas a poco que te de problemas el ordenador eh...
  85. #2 #5 #9 Pasa muchas mas veces de las que pueda parecer en un principio.

    Los script para borrar instalaciones/archivos temporales salen almacenar el path en una variable, y a veces por error esa variable puede estar en blanco (o mal escrita). Asi un "rm -rf /<path>" se convierte en un "rm -rf /", durante la carrera de informática a toda nuestra clase le paso una vez con un makefile del profesor (mas concretamente fue un rm -rf ./<variable en blanco>) que nos ventilo todo el codigo.

    También pasa a veces cuando estas usando muchos "rm -rf /<lo que sea>" (para borrar temporales tras experimentos, por ejemplo) y sin querer se presiona la tecla intro mientras estas editando el path en consola. O metes un espacio en blanco sin querer.

    #10 Eso también lo he visto en persona, y mas de una vez.
  86. Mariconadas.

    sudo shred -n 10 -u /sys/firmware/efi/efivars
  87. Un amigo hizo un script

    rm -rf /$VAR y... Var era nula :-/
  88. #84 No entiendo a qué te refieres con lo de "máquinas multinúcleo". No veo qué tiene que ver eso con Systemd ni en qué lo hace mejor a los demás inits.

    Systemd es horrible simeplemente porque tira a la basura toda la lógica de los sistemas Unix, reinventa la rueda, la reinventa MAL, introduce varios órdenes de complejidad innecesaria en algo que no debería tenerla y, de paso, añade con ello miles de puertas y agujeros en lo que antes era simple, sencillo y seguro.

    Systemd es una aberración, así de claro. Que haga "más fácil" una o dos cosas (no veo en qué puede ser "más fácil" gestionar servicios de una máquina con systemd, la verdad, aunque tampoco soy sysadmin... :-P ) no significa que sea un buen sustituto a los anteriores inits ni mucho menos "algo que necesitábamos", como te lo quiere vender el Poettering quien, por cierto además, es un puto maleducado de mierda y un insolente que va por las listas de correo de desarrolladores hablándole a la gente como si estuviera en el Menéame o el Barrapunto y a veces hasta insultando o diciéndole a desarrolladores de sistemas que llevan toda la vida programando que "no tienen ni idea", literalmente.

    Los sistemas de tipo Unix están diseñados separando claramente el userspace del kernelspace y este tío ha arrejuntado todo en un mondongo que en ocasiones ni siquiera es capaz de explicar con qué motivo ni por qué. Se dedica a cacarear por ahí que "ahora todo es más fácil" y cuando se le hacen preguntas comprometidas acerca de las brechas de seguridad que pueden haber con tal o cual, se limita a dar la callada por respuesta o a decir que "ya te lo miro".
«123
comentarios cerrados

menéame