Bombas fork

La bomba fork es un ataque de tipo DoS para sistemas operativos. Se llama así por la función fork() de UNIX, encargada de crear procesos hijos y base de este ataque. Mediante unas pocas líneas de código ejecutadas por cualquier usuario de manera local, se puede tumbar cualquier máquina en cuestión de segundos. No es algo que se pueda parchear fácilmente debido a que no es ningún fallo ni ninguna vulnerabilidad. Tampoco se puede identificar como virus o malware, porque tampoco lo es. Una bomba fork suele hacer uso de algo tan sencillo como un bucle infinito dentro del cual se crea un proceso hijo. Así, el número de procesos en el sistema crece de forma incontrolada hasta consumir los recursos de la máquina (memoria RAM y procesador), quedando colgada. ¿El resultado? Pues que hay que reiniciar a las bravas (léase tirando del cable o pulsando el botón), pero nada más. No supone ningún peligro, salvo que estemos trabajando con algún documento y no hayamos guardado…

En resumidas cuentas, la bomba fork no es un agujero en la seguridad de los sistemas operativos porque no produce ningún daño (salvo la molestia), porque lo tiene que ejecutar el propio usuario del sistema (luego es un suicidio en toda regla) y porque es más bien una característica de los lenguajes de programación y el resultado de un programador patoso. Vamos, que es lo mismo que tirar del cable de alimentación queriendo. Aun así, no deja de ser una bonita curiosidad.

Vamos a ver unos ejemplos. Empecemos con Linux. Existe una bomba fork para este sistema que tiene el honor de ser considerada «la bomba más bonita jamás creada», tanto por su simplicidad como por su elegancia. El código es el siguiente:

[code lang=»bash»]:() { : | : & };:[/code]

Así de simple. Si introducimos lo anterior en una consola de Linux, probablemente el ordenador quedará inmediatamente colgado. O no. Este código se conoce desde hace bastante tiempo y es posible que en vuestra distribución de Linux ya no funcione porque hayan implementado algún tipo de protección contra usuarios suicidas. Por ejemplo, en mi Fedora 10 no funciona. Si lo analizamos, es lo mismo que escribir lo siguiente:

[code lang=»bash»]funcion() {
funcion | funcion &
};
funcion[/code]

Ahora está mucho más claro: definimos una función y luego la llamamos. Dentro de la misma, se llama a sí misma y el resultado se pasa por una tubería a ella misma de nuevo y todo estos se ejecuta en segundo plano (carácter «&»). Es decir, de cada proceso salen dos nuevos, y de cada uno de ellos, otros dos, y así hasta que el sistema operativo lo permita.

Windows también tiene su versión de línea de comandos, y tiene esta pinta:

[code lang=»plain»]:s
start %0
%0 | %0
goto s[/code]

Hace lo mismo que la anterior. Basta con guardar esto en un fichero de texto y cambiarle la extensión de «.txt» a «.bat». Tras esto, ejecutar y disfrutar del espectáculo. Guardad todo lo que estéis haciendo primero, que esta sí que funciona, aunque no deja el sistema totalmente colgado, porque llega un momento que los procesos creados empiezan a dar errores de aplicación y la carga del sistema baja, con lo que se puede llegar a hacer algo, pero de todas formas hay que acabar reiniciando.

Y ahora vienen las bombas buenas. Las que dejan al sistema congelado sí o sí, tanto para Linux como para Windows, en lenguaje C. La primera la del pingüino:

[code lang=»c»]#include <unistd.h>

int main(void) {
while(1)
fork();
return 0;
}[/code]

Copiad este código en un archivo y guardadlo como «.c». Tras esto, compiladlo con nuestro querido gcc —sí, de acuerdo, es una mierda, pero es nuestra mierda— y lanzad el binario. It works!

Bien, y como lo prometido es deuda, la versión de Windows (esta es cosecha propia, seguro que las hay mejores):

[code lang=»c»]#include <windows.h>

int main (void) {
STARTUPINFO si;
PROCESS_INFORMATION pi;

ZeroMemory( &si, sizeof(si) );
si.cb = sizeof(si);
ZeroMemory( π, sizeof(pi) );

while(1)
CreateProcess ("bomba.exe", NULL, NULL, NULL, TRUE, 0, NULL, NULL, &si, π);
return 0;
}[/code]

Aquí el archivo se llama «bomba.cpp» y al compilar queda como «bomba.exe», por lo que la llamada anterior hace que se inicie a sí mismo. Para los que lo queráis probar, podéis descargar el ejecutable desde aquí.

Como ya hemos comentado, no es algo grave para ningún sistema operativo y un ordenador personal, pero sí que hay que tenerlo en cuenta cuando se trata de servidores. Los administradores deben tener cuidado y configurar adecuadamente los equipos para evitar que usuarios tocahuevos con acceso shell puedan darles un disgusto. Así pues, la solución que pueden aplicar es limitar el número de procesos que puede crear un usuario. Con 20 son más que suficientes. En Linux, mediante el comando ulimit -a podemos ver el número de procesos máximo de nuestro usuario. En mi distribución, el límite está en 1024, algo alto. Esto se puede modificar en el archivo /etc/security/limits.conf.

Para más información y para ver bombas en otros lenguajes de programación, visitad la página de la Wikipedia (primer enlace).