Bomba de horquilla

El concepto detrás de una bomba de tenedor — los procesos se replican continuamente, causando potencialmente una denegación de servicio

En informática, una bomba fork (también llamada rabbit virus o wabbit) es un ataque de denegación de servicio en el que un proceso se replica a sí mismo para agotar los recursos disponibles del sistema, ralentizando o colapsando el sistema debido a la escasez de recursos.

Historia

Alrededor de 1978, se informó que una variante temprana de una bomba bifurcada llamada wabbit se ejecutaba en un System/360. Puede haber descendido de un ataque similar llamado RABBITS informado desde 1969 en un Burroughs 5500 en la Universidad de Washington.

Implementación

Las bombas de bifurcación funcionan consumiendo tiempo de CPU en el proceso de bifurcación y saturando la tabla de procesos del sistema operativo. Una implementación básica de una bomba de horquilla es un bucle infinito que lanza repetidamente nuevas copias de sí mismo.

En los sistemas operativos similares a Unix, las bombas de bifurcación generalmente se escriben para usar la llamada al sistema de bifurcación. Como los procesos bifurcados también son copias del primer programa, una vez que reanudan la ejecución desde la siguiente dirección en el puntero del marco, continúan bifurcándose sin cesar dentro de su propia copia del mismo ciclo infinito; esto tiene el efecto de provocar un crecimiento exponencial en los procesos. Como los sistemas Unix modernos generalmente usan una técnica de administración de recursos de copia en escritura cuando se bifurcan nuevos procesos, una bomba de bifurcación generalmente no saturará la memoria de dicho sistema.

Los sistemas operativos de Microsoft Windows no tienen una funcionalidad equivalente a la llamada del sistema de bifurcación de Unix; una bomba de bifurcación en un sistema operativo de este tipo debe, por lo tanto, crear un nuevo proceso en lugar de bifurcarse a partir de uno existente.

Sin embargo, en Microsoft Windows, se puede crear una bomba de bifurcación en un archivo por lotes con contenido %0|%0. Si se ejecuta este archivo por lotes, comienza a crear copias ilimitadas de sí mismo.

Un ejemplo clásico de una bomba de horquilla es uno escrito en el shell de Unix :(){:|:& };:, posiblemente de 1999, que puede entenderse más fácilmente como

tenedor() {} tenedor Silencio tenedor "}tenedor

En él, una función se define (fork()) llamándose a sí misma (fork), luego canalizando (|) su resultado a un trabajo en segundo plano de sí mismo (&).

El código que usa dos puntos : como el nombre de la función no es válido en un shell como lo define POSIX, que solo permite caracteres alfanuméricos y guiones bajos en los nombres de las funciones. Sin embargo, su uso está permitido en GNU Bash como una extensión.

La primera formulación de la bomba de horquilla de shell de Unix se ha propuesto como una obra de arte anónima.

Prevención

Dado que el modo de funcionamiento de una bomba de bifurcación está completamente encapsulado mediante la creación de nuevos procesos, una forma de evitar que una bomba de bifurcación afecte gravemente a todo el sistema es limitar la cantidad máxima de procesos que puede poseer un solo usuario. En Linux, esto se puede lograr usando la utilidad ulimit; por ejemplo, el comando ulimit -u 30 limitaría al usuario afectado a un máximo de treinta procesos propios. En sistemas habilitados para PAM, este límite también se puede establecer en /etc/security/limits.conf, y en FreeBSD, el administrador del sistema puede poner límites en /etc/login.conf. Los sistemas Linux modernos también permiten una prevención de bomba de bifurcación de grano más fino a través de cgroups y controladores de número de proceso (PID).