Bombas Fork
Damián Domingo 22 de Abril del 2007
Leyendo un artículo en Kriptópolis me entró la curiosidad sobre las bombas fork, y su potencial peligro al presentar la posibilidad de que un usuario, sin privilegios, “tire” el sistema al que pertenece sin más que escribir una línea de código. Suena como a película hollywoodense sobre “hackers”, pero es cierto.
El término computacional fork fue acuñado en los sistemas Unix; se refiere a la capacidad que tiene un proceso de generar procesos hijos que son copias de él mismo. Cuando un proceso se copia a sí mismo y genera otro proceso se dice que ha “hecho fork”.
La bomba fork que se describe en dicho artículo se logra ejecutando en una terminal (bash) dentro de Linux, basado en Unix, este comando:
:(){ :|:& };:
Ahora bien, ¿qué hace este comando tan extraño? Autorreplica un proceso indefinidamente (ya que el comando inicia bucle infnito), monopolizando los tiempos del procesador y además llenando la memoria del sistema, logrando finalmente un DoS (Denial of Service); pues deja a la máquina, en donde se ejecutó, congelada. Ya lo he probado en mi Fedora y funciona tal cual.
¿Es esto un bug de Linux? No, no lo es. Es simplemente un problema de configuración, que se puede arreglar de manera muy fácil, agregando al final del archivo /etc/security/limits.conf la siguiente línea:
* hard nproc 1000
Esto va a límitar el número de procesos que un usuario puede crear.
Ahora al meollo. La importancia de esto radica en que potencialmente podrías “tirar” el servidor de alumnos de tu universidad simplemente ejecutando ese comando dentro de tu cuenta de alumno, o podrías “tirar” tu propia máquina (aunque no tendría mucho sentido). La mayoría de los administradores de sistemas saben (o deberían saber) de este tipo de bombas y cómo configurar bien un sistema Unix. Así que es poco probable que puedas explotar esto, ¿o no?
Para finalizar. No todas las distribuciones GNU/Linux “por defecto” son vulnerables, aunque por desgracia se menciona que casi todas de las más conocidas, y hasta algunos sistemas *BSD. La moraleja es que hay que tener cuidado con la configuración de los sistemas, porque una mala configuración puede hacer que el sistema “más robusto” pueda ser tirado por un chamaco de 12 años.
Más información:
