El Módem

Hace unos días un usuario de Kriptópolis publicó algo que había “descubierto”: al ejecutar un comando desde consola en Linux (como usuario normal) el sistema se colgaba al cabo de un rato. En realidad se trataba de algo bastante antiguo. ¿Qué es lo que ocurría? Pues el comando ocasionaba una bomba fork.

En forma simple: Los Sistemas Operativos (Windows, Linux, etc.) implementan la función fork mediante la cual un proceso (o programa) puede “clonarse”, es decir, generar un proceso idéntico (un proceso hijo), esta característica es muy útil cuando se usa correctamente, pero al usarla mal, puede generar problemas. Una bomba fork aprovecha esta característica, creando procesos que a la vez crean más procesos, y así hasta que el Sistema Operativo se cuelgue (pues se queda sin recursos). En Kriptólis lo explican bien y muestran la forma de prevenir esto que es la que yo mostraré a continuación.

(…)una bomba fork no es una bomba lógica, ni tampoco un fallo del kernel. (…)Tampoco es en sí mismo una vulnerabilidad (aunque sí pueda convertirse en alguna rara ocasión en un problema). De hecho en la inmensa mayoría de los casos no tiene ninguna importancia, y no pasa de ser una curiosidad.

Primero algunas aclaraciones: la “bomba fork” inutiliza al equipo localmente (no es un gusano que se propaga por la red) y para “lanzarla” es necesario ejecutar algunas cosas por consola, o realizar un programa (en C por ejemplo) en forma incorrecta. El mismo usuario debe lanzarla. Así que algunos consejos:

Si es que usas una máquina con un sólo usuario, en tu hogar, no ejecutes cosas que no sabes qué es lo que son (no hagas casos en foros o canales de chat en donde te digan: “ejecuta tal comando en terminal para tal cosa”) si es que no provienen de alguien confiable.

Si estás en tu hogar y la PC la utilizan varias personas, es posible limitar el acceso a consola de los diferentes usuarios (eso lo explicaré en un próximo post), por ejemplo, sólo tu puedes acceder a consola, y puedes bloquear su uso a tu hermano menor.

Si estás en un servidor o en un entorno de trabajo multiusuario, el administrador del sistema es quien tiene la responsabilidad de ocuparse de dichas cosas (limitando el acceso a consola, seteando el máximo número de procesos por usuario, etc.). Es su trabajo y su responsabilidad el conocer estas cosas.

Ahora vayamos a las pruebas (y protección) de la dichosa “bomba fork”:

Prueba

Abre consola e ingresa el comando ulimit -a (esto no colgará el sistema, simplemente muestra los límites actuales para los usuarios):

$ 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

La línea que nos interesa es:

max user processes              (-u) unlimited

Nos dice que los usuarios pueden crear procesos ilimitadamente. En Ubuntu está seteado así pero, por ejemplo, en Suse, viene con un límite a 4096, con lo cual, está protegido ante una bomba fork (al llegar al límite e intentar crear más procesos, el SO no se lo permitirá). Sería bueno que en una distribución orientada al usuario doméstico, este parámetro venga limitado por defecto.

Ahora probaremos la bomba. Primero, guarda todos los archivos en los que estés trabajando y cierra los programas, pues es posible que tu sistema se cuelgue (dependiendo de la distribución). Abre consola e ingresa:

:(){ :|:& };:

Como se podrán dar cuenta, es difícil que un usuario ingrese por accidente un código similar desde consola.

Luego de un momento, el SO quedará “colgado”, pues lo anterior crea procesos en forma infinita (forks o clones). Windows no está libre de esto, para tener una bomba fork, es necesario crear un archivo bat con el siguiente código extraído de la Wikipedia (no lo he probado):

:s
start %0
goto s

Protección
Para protegernos de esto, es necesario editar un archivo que limita el máximo de procesos por usuario, el archivo en cuestión es /etc/security/limits.conf. Desde consola, abrimos para edición este archivo como superusuario (root) o con sudo en el caso de Ubuntu. Pueden usar el editor que les sea más cómodo:

en Gnome:

sudo gedit /etc/security/limits.conf

para KDE:

sudo kate /etc/security/limits.conf

o desde la misma consola:

sudo vim /etc/security/limits.conf

Al final de dicho archivo, añadiremos una línea que hará que el máximo número de procesos esté limitado. Yo he puedo el máximo en 1000 procesos (la cual es una cifra razonable), pero pueden probar otro número (por ejemplo 4096 como en Suse). La línea a añadir es:

*    hard    nproc    1000

Guardamos el archivo y reiniciamos el sistema. Luego, ejecutamos otra vez ulimit -a para comprobar que el límite esté establecido:

max user processes              (-u) 1000

Vemos que está seteado correctamente, ejecutamos nuevamente el código de la bomba fork y luego de un momento, el sistema nos advertirá:

bash: fork: Recurso temporalmente no disponible

Nos daremos cuenta que tenemos el control del SO y que no se ha colgado. Matamos el proceso con CTRL + C y cerramos nuestra ventana de terminal con CTRL + D y listo.

Otra opción, es utilizar Fork Bomb Defuser, un módulo para el kernel que detecta y “desactiva” las bombas fork configurando el máximo de procesos por segundo y el máximo de procesos por usuario. No lo he probado todavía.