Baires Norte Lug

Hace unas semanas atrás con Diego (alias scan) amigo e integrante del LUG manteníamos la siguiente charla por Gtalk:
(21:03:53) diexxxxgmail.com: mmm..
(21:04:23) diexxxx@gmail.com: Conoces este error logico de linux/unix/bsd/sun
(21:04:27) diexx@gmail.com: :(){ :|:& };:
(21:04:39) sebasxxx@gmail.com/Gaim: eh? jajja
(21:04:57) diexxxx@gmail.com: tipealo en la consola
(21:05:00) diexxxx@gmail.com: y vas a ver
(21:05:10) diexxxxgmail.com: vos que decís que Linux es lo mejor
(21:05:12) diexxxx@gmail.com: :P
Efectivamente si tipean en una consola esa sentencia verán como un sistema sin limite de procesos queda knock out.
Veamos que significa esa sentencia:

:(){ :|:& };:

“:” es el nombre de la función

:() -> creamos la función
{
:|:& -> llamamos a la propia función redirigiendo la salida estándar de la función a la entrada estándar de la misma función, y el proceso queda en background
}
;: -> llamamos a la función recursiva ( con llamarla una vez bastará, ya que ella misma será la encargada de volverse a llamar sin límite )

También podrían haber utilizado algo así:

forkbomb () {
forkbomb | forkbomb &
}
forkbomb

Lo interesante que esto dio la vuelta al mundo y fue publicado en portada en muchos sites de seguridad. En realidad es algo bastante viejo inclusive tiene una entrada en la wikipedia.
Muchos usuarios de Windows esgrimieron esta situación como una vulnerabilidad y se regocijaron sin pensar que ellos tampoco están exentos.
La versión Windows de ese mismo Fork Bomb es un .bat con este contenido:

:s
start %0
goto s

Otras variantes de fork bomb podría ser esta:

echo “\$0&\$0″>_;chmod +x _;./_

o esta otra:
#!/bin/sh
$0 & $0

El efecto siempre es el mismo. La diferencia que en Windows es incontrolable en cambio en un *nix se puede controlar o incluso evitar como veremos mas adelante.

A este efecto se lo denomina wabbit, porque se reproduce por la memoria sin control, no es un virus, no infecta ni archivos ni programas, simplemente sobrecarga el sistema generando infinitos procesos forks. Como si se tratara de un conejo…

Aparentemente el sistema se cuelga. Pero al rato el wabbit muere porque Linux no lo deja continuar. Cuando un proceso consume demasiados recursos el núcleo de Linux terminará por matarlo con una señal de “fork failed”. Claro que eso toma bastante tiempo, sobre todo en estas épocas de cantidades enormes de RAM y CPUs muy potentes (sera culpa del Vista?). Lo que es todo un ejemplo de estabilidad.
También Existen otros tipos de bombas como por ejemplo la siguiente si queremos llenar el disco :

$ yes>file&yes>>file

Porque pasa esto?
Muy simple la mayoria de las distribuciones vienen por defecto sin limites y cualquiera usuario sin derechos puede ejecutar este tipo de cosas.

Es cierto que afecta a todos los *nix?
No es así, Mac es inmune a este problema, también Solaris y FreeBSD porque por defecto vienen bien seteados los limites del sistema.
También depende del shell que se este utilizando. Si utilizan csh no se van a ver afectados ya que la sintaxis es diferente claro.

Solución?
Una posible solución es entrar en el equipo en cuestión por telnet o ssh y hacer un ciclo while matando todo los procesos correspondientes al usuario en cuestión que ejecuto el fork infinito.

while true
do
killall -9 -u usuario bash
done

Aunque dudo que alguien llegue a averiguar que usuario hizo eso y tipear tan rápido como para no dejar que se reproduzca a tal punto de no dejar hacer nada.

La prevención mas efectiva es usar ulimit:
Por ejemplo en mi notebook con Ubuntu si hago un ulimit devuelve:
sebastian@xunilda:~$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 20
file size (blocks, -f) unlimited
pending signals (-i) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) unlimited
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

Lo cual puede llegar a ser peligroso…jejeje.
Así que limitamos la cantidad de procesos con:
$ ulimit -u 100

corremos de vuelta la bomba y obtenemos:
-bash: fork: Resource temporarily unavailable

Lo mismo si limito el tamaño máximo de archivo que serviría para el caso de la bomba que llena el disco:
$ ulimit -f 100

Si queremos hacer permanente los cambios podemos editar el siguiente archivo para sistemas con kernel 2.6.x:
/etc/security/limits.conf

Agregamos por ejemplo una linea que diga
* hard nproc 100

En este caso le decimos que cualquier usuario puede abrir hasta 100 procesos y no mas.
Para el caso de sistemas con kernels de la serie 2.4.x deben colocar las sentencia ulimit con los parámetros que queremos en /etc/bash.bashrc para un limite global o en .bashrc del home del usuario para algo mas personal.

Cual es el limite correcto?
No lo se, uds. prueben con sus equipos. Vean de abrir todo lo que utilizan normalmente y midan cuantos procesos estan en ejecución, cuanta memoria utilizan, etc. Luego realizan los seteos correspondientes.

Moraleja: Si tienen un equipo en producción no dejen nada librado al azar, hagan todos los chequeos y configuraciones necesarias, tienen todas las herramientas al alcance.
Linux o cualquier *nix puede llegar a colapsarse, pero es muy difícil, incluso provocándolo.

ESTE TEXTO SE PUBLICA BAJO LICENCIA CREATIVE COMMONS BY-NC-SA 2.5 AR.

Por lo tanto, usted es libre de: 1) Copiarlo, distribuirlo y exhibirlo. 2) Hacer obras derivadas. Bajo las siguientes condiciones: 1) Debe dar atribución mencionando el nombre del autor y del LUG Zona Norte. En caso de las notas que no llevan firma, mencionar sólo el nombre del LUG.
2) Usted no puede usar esta obra con fines comerciales. 3) Si usted altera, transforma, o crea sobre este texto, sólo podrá distribuir la obra derivada resultante bajo una licencia idéntica a ésta.

Más detalles y texto legal de la licencia en: http://creativecommons.org/licenses/by-nc-sa/2.5/ar