Una funzione fork indica nei sistemi Unix il programma che, partendo da un processo “padre”, genera processi “figli” tramite repliche multiple. Se questo processo continua fino ad esaurire le risorse del sistema, causando un vero e proprio attacco di tipo DoS (Denial of Service), vuol dire che siamo stati colpiti da una fork-bomb, siamo cioè bersaglio di un attacco ForkBomb.
Appena viene lanciato questo attacco, il sistema è di fatto costretto ad eseguirne i comandi ignorando tutto il resto ed anche la tastiera e il mouse diventano assenti. Il sistema si blocca completamente ed è necessario un reset hardware per farlo ripartire.
Come è stato detto in precedenza, tutti i sistemi *nix sono suscettibili a questo attacco, mentre per i sistemi Windows occorrono tecniche e capacità maggiori per poterlo effettuare con successo.
Nella storia dei virus informatici, anche a questo tipo di attacco è stato dato un nome specifico e cioé Wabbit che indica un programma che genera copie di sé stesso fino al blocco del sistema. Il nome fu coniato nei primi Anni 70, derivandolo da un virus più noto, chiamato Rabbit, per indicare un programma malevolo di tipo wormable.
Indice degli argomenti
Cos’è e come funziona un attacco ForkBomb
Vediamo ora nel dettaglio come si costruisce un attacco ForkBomb facendo un semplice esempio pratico.
Il metodo più semplice consiste nel far eseguire dalla macchina vittima un semplice comando. Ad esempio, in una finestra terminale di Linux scriveremo:
:(){ :|: & };:
questo comando ha il seguente significato:
- :() definisce una funzione chiamata “:”
- { } racchiude il comando da eseguire
- :|: esegue il comando ricorsivamente
- & esegue il comando precedente in background
- ; separa la funzione che definisce il comando a sinistra dal comando successivo
- : esegue infine il comando, che consiste nella funzione nuova appena creata.
L’esecuzione di questo comando, che non necessita di privilegi root, crea dunque una serie infinita di processi “figli” così che il sistema esaurisce rapidamente tutte le risorse (memoria, CPU) fino al blocco totale.
Utilizzando vari linguaggi di programmazione è possibile sfruttare metodi simili per mettere in pratica un attacco ForkBomb. Ad esempio, in linguaggio C scriveremo:
#include <unistd.h>
int main()
{
while(1) fork();
}
Esistono poi analoghi script in Java, C++, C#, Ruby, Perl, Go, PHP, solo per citare i più noti.
Come difendersi da un attacco ForkBomb
La possibile contromisura a questo attacco è altrettanto semplice: limitare il possibile numero di processi che possono essere creati all’interno del sistema operativo.
In Linux, per esempio, si può ricorrere alla funzione ulimit, tenendo presente, però, il grande svantaggio che essendo legata alla sessione corrente, al momento del riavvio del computer, è necessario ridare il comando, rendendo molto tediosa la manutenzione dei sistemi in questo modo.
Si può, in alternativa, indicare la stessa limitazione usando il file /etc/security/limits.conf ed indicando che questa limitazione deve valere per tutti gli utenti del computer.
Ogni riga di questo file descrive un limite per un utente nella forma:
<domain> <type> <item> <value>
Nel campo <value> compare il parametro <nproc> che permette di configurare il numero massimo di processi desiderato.
Quindi per un generico utente Mrossi, indicheremo il limite ad esempio in questo modo:
<Mrossi Hard nproc 500>
indicando con <Hard> che si vuole stabilire un limite all’interno dell’hardware del dispositivo.
Purtroppo, anche questo rimedio presenta una debolezza in quanto un utente con elevati privilegi o un processo con privilegi di root, potrà comunque iniziare un attacco ForkBomb, indipendentemente da questa configurazione.
Attacco ForkBomb e nuovi campi di ricerca
Varie organizzazioni internazionali (IEEE, ad esempio, cioè l’Institute of Electrical and Electronic Engineer) hanno spesso pubblicato articoli sull’argomento, cercando una soluzione generale al problema, attraverso metodologie di limitazione del consumo di risorse, o attraverso metodi più intelligenti di rilevazione di questo attacco.
In una raccomandazione IETF (Internet Engineering Task Force), la draft-ietf-p2psip-sip-04, proposta come standard nel 2010 a proposito del protocollo SIP (Session Initiation Protocol), ovvero il ben noto protocollo di rete di controllo del livello applicativo usato per creare, modificare, e terminare sessioni tra uno o più partecipanti, si legge testualmente nel paragrafo intitolato Fork Explosion:
[…Because SIP includes a forking capability (the ability to retarget to multiple recipients), fork bombs are a potential DoS concern…].
Come si vede, quindi, il problema degli attacchi ForkBomb può impattare anche protocolli di rete e non solo macchine *nix.
Vulnerabilità ad un attacco ForkBomb
Nel database NIST (National Institute of Standards and Technology) è possibile recuperare informazioni su vulnerabilità note, ufficialmente classificate e dovute alla possibilità di essere causate da forkbomb.
Solo per fare qualche esempio, riportiamo di seguito alcune vulnerabilità CVE (Common Vulnerability Enumeration) molto recenti catalogate dal 2013 ad oggi.
Riportiamo qui di seguito alcuni esempi:
- CVE-2013-6801: Microsoft Word 2003 SP2 and SP3 on Windows XP SP3 allows remote attackers to cause a denial of service (CPU consumption) via a malformed .doc file containing an embedded image, as demonstrated by word2003forkbomb.doc, related to a “fork bomb” issue.
- CVE-2014-6271: GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution, aka “ShellShock.
Questa famosa vulnerabilità può essere sfruttata, ad esempio, eseguendo il comando forkbomb da remoto per colpire un server vittima, quindi le possibilità di attacco sono anche più numerose dell’attacco diretto.
- CVE-2011-3918: The Zygote process in Android 4.0.3 and earlier accepts fork requests from processes with arbitrary UIDs, which allows remote attackers to cause a denial of service (reboot loop) via a crafted application.
Sfruttando questa vulnerabilità di Android 4.0.3, è possibile anche costruire App che eseguono un attacco forkbomb.
- CVE-2017-6198: The Supervisor in Sandstorm doesn’t set and enforce the resource limits of a process. This allows remote attackers to cause a denial of service by launching a “fork bomb” in the sandbox, or by using a large amount of disk space.
Conclusioni
L’attacco ForkBomb causa ancora oggi effetti devastanti sui sistemi, se il programma che lo contiene viene lanciato senza controllo e inoltre tutti i sistemi operativi sono attaccabili.
Sono sufficienti quattro o cinque righe di programma per bloccare istantaneamente il sistema e se fosse installato su un server critico o una macchina che sta eseguendo simulazioni o su un dispositivo chiave per la propria rete, si dovranno prevedere perdita di servizi, ore di lavoro e forse anche di dati preziosi.
Una vera cura preventiva non esiste e nemmeno una mitigazione definitiva sembra possibile. Best practice di settore consigliano, comunque, di installare esclusivamente software fidati e applicare una corretta gestione dei privilegi di utenti e/o processi interni delle macchine per contenere il rischio.
