Aktion 23 Fnorum

Bombenbau-Anleitungen (für angehende Informatiker)
Fork-Bombe
Eine Fork-Bombe ist ein Programm/Skript oder ein Kommandozeilen-Befehl der unbeschränkt
forkt und sich dadurch bombenartig vervielfältigt.
Ein Beispiel für die Shell ist diese Zeile, die auch auf der Kommandozeile (der Bash und ähnlicher
Shells) funktioniert:
:(){ :|:& };:
Schöner sieht diese Bombe auf dem Bild vom Debian-Paket pydance-music aus, das man mit dem
Lied forkbomb.ogg unter /usr/share/games/pydance/songs/forkbomb/ findet:

Hier wird zunächst die Funktion : definiert (bis zum Semikolon) und anschließend wird diese
ausgeführt.
Danach geht es rund: Die Funktion ruft sich zweifach selbst auf und jeder dieser neuen Aufrufe ruft
sich auch zweifach auf und so weiter.
Die Pipe (|) sorgt dafür dass die Shell sich forkt um das erste : auszuführen (es muss ja gleichzeitig
mit dem zweiten laufen, um seine Ausgabe als Eingabe für das zweite zu verwenden); das & sorgt
dafür, dass die Shell sich forkt, um den ganzen Ausdruck (also : | :) im Hintergrund auszuführen.
Jeder Funktionsaufruf sorgt also für zwei neue Prozesse; diese führen den gleichen Code selber
ebenfalls aus (da die Funktion sich ja selber aufruft), erzeugen als ebenso zwei neue Prozesse. Das
sind schon vier; bei der nächsten Runde werden es 8; usw..
Wie beim Explodieren von A-Bomben hat man auch hier anfänglich ein exponentielles Wachstum;
daher der Name der Fork-Bombe und deshalb verwendet das obige Bild von pydance-music als
Grundlage ein Bild vom Mock-Up (Attrappe) der Little Boy.

Dieses (auf 50 % verkleinerte und per Rechtsklick vergrößerbare) Bild von wikipedia.de zeigt das
exponentielle Wachstum, bei dem jeder einzelne Prozess zwei weitere auslöst.
Ein äquivalentes Beispiel der obigen Zeile für die Shell gibt es natürlich auch für Batch-Dateien
(MS-Windows):
%0|%0
Diese 5 Zeichen in einer Text-Datei mit Namen beispiel.bat reichen aus; zum Ausführen reicht dann
ein Doppelklick.
In C sieht die Fork-Bombe so aus:
#include <unistd.h>
int main (int argc, char* argv[]) { for(;;) fork(); }
In der Praxis zeigen sich einige Unterschiede zwischen den verschiedenen Varianten der Fork-
Bombe: Die letzte Version, mittels "gcc -O2 -o forkbomb forkbomb.c" compiliert, bringt SuSE 11.1
augenblicklich so schnell und nachhaltig zum Stehen, das ein in einem anderen Fenster laufendes
top nichts davon anzeigt und das Betriebssystem zumindest eine Stunde lang nur auf den Magic
System Key Request reagiert, selbst wenn die Forkbombe nur von einem einfachen User ausgeführt
wird, während die Shell-Version es nur träge macht, selbst wenn die Shell-Version von root
ausgeführt wird.
Der Grund hierfür sind Limitierungen von (2009) modernen Betriebssysteme, die meist auch beim
Superuser wirksam sind. Beispielsweiese läßt sich das SuSE 11.1 durch die C-Version nicht
aufhängen, wenn man in die C-Version vor jedem fork ein printf einfügt, oder hinter jedem fork
eine Endlosschleife wie for(;;) einfügt, denn das reduziert die Geschwindigkeit des Forkens und gibt
mehr Zeit zum Limitieren.
Die Wirkung der Fork-Bombe hängt auch vom Nice-Level bzw. der Priorität ab: Je niedriger der
Nice-Level bzw. je höher die Priorität desto schwerer ist sie zu stoppen.

Verwendet werden Fork-Bomben unter Anderem zum Reduzieren der Rechner-Geschwindigkeit
(für einzelne Prozesse) und auch zum Testen von Limitierungen beispielsweise mittels ulimit oder
/etc/security/limits.conf: Wurde richtig limitiert, kann eine Fork-Bombe nicht stören; hat ein User
keine Limitierungen, was traditionellerweise beim Superuser der Fall ist, MUß der Rechner
hierdurch hängen bleiben weil die Prozesse Resourcen (Speicher, CPU-Zeit) belegen, die durch das
exponentielle Wachstum rasch erschöpft sind, aber Notfall-Aktionen wie z. B. der Magic System
Key Request, müssen weiterhin funktionieren.
Ein weiteres Anwendungsfeld für Fork-Bomben ist das Überprüfen von Echtzeit-Eigenschaften wie
Interruptlatzenzeiten unter erschwerten Bedingungen, beispielsweise von RTAI.
Unter BSD findet man ein Fork-Bomb-Programm normalerweise unter ports/packages/pkgsrc, zum
Üben der System-Administration: http://bsdwiki.reedmedia.net/wiki/Monitor_disk_input--
output.html.
Eine Fork-Bombe ist eine der wenigen Möglichkeiten einen Rechner gezielt zum Hängen bleiben
(hangup) zu bringen um beispielsweise Watchdogs, die bei den meisten Server- u. Workstation-
Mainboards sowie IPMI-Modulen integriert sind, auch remote zu testen.
Allerdings eignen sich Forkbomben nur wenig zum Belasten von CPUs/GPUs/Kernen: Wie auch
Messungen mit Leistungsmessern zeigen, ist der Stromverbrauch mit einer Forkbombe weit
geringer als mit einem CPUburn-Programm, also einem Programm das optimiert wurde um (alle)
CPUs/GPUs/Cores durch möglichst hohen Stromverbrauch möglichst stark zu erwärmen. Und
hierbei zeigen sich die besten und damit höchsten Werte mit den Programmen der CPU-Hersteller,
die jeweils für nur eine Prozessor-Familie erstellt werden und meist "confidential" sind.

Man kann zwar versuchen mit einer Fork-Bombe die CPUs noch zu mehr beschäftigen indem man
sie nebenbei noch etwas rechnen läßt, z. B. mittels
:(){ :|md5sum /dev/urandom&:& };:
oder
:(){ :|bzip2 -c /dev/zero > /dev/null&:& };:
aber damit wird meist nicht mehr Leistung verbraucht als mit einer einfachen Fork-Bombe.
Hierzu ein paar Werte der Stromaufnahme von meinem neuen Server im Februar 2010, mit dem
Mainboard X8SAX, BIOS t1070 mit aktiviertem TourboBoost und SMT, CPU Core i7 940, PSU
PWS-865-PQ, 6x 1 GiB RAM, 2 TB SATA II HDD, Nvidia GeForce 9600 GT, unter Debian 5.03
(Lenny and a half) 64 Bit sofern nichts anderes angegeben ist:
4,6 Watt im Standby (nach poweroff)
134 Watt mit BIOS-Meldungen oder ruhendem Desktop
165 Watt mit md5sum Fork-Bombe
165 Watt mit bzip2 Fork-Bombe
168 Watt mit simpler simple Fork-Bombe unter Knoppix (32 Bit)
230 Watt mit burnP6 mit 1 Thread/Core (d. h. 8 Threads wg. SMT)
260 Watt mit Nehalem-EP Power Thermal Utility Rev 1.4, mit 1 Thread/Core (d. h. 8 Threads wg
SMT), wobei es 32-Bit-Bibliotheken verwendet.
275 Watt wenn zusätzlich zum letzten noch Glxgears läuft und die Grafikkarte belastet.
Hierbei kann man noch mehr Leistung erreichen, beispielsweise um den Rechner in einer
Klimakammer zu testen oder um die Heizung im gleichen Raum zu unterstützen oder um das
Netzteil zu testen, indem man auch die Festplatte und das RAM auslastet und für die Grafikkarte
einen "Power Virus" wie Furmark (1.8) verwendet. Die maximale Leistung zu erreichen ist aber
nicht-trivial, weil die CPU-Cores nicht gleichzeitig sich selbst und andere Komponenten auslasten
können, so das man die optimalen Prioritäten und Anzahlen der jeweiligen Threads sowie deren
Verteilung auf die NUMA-Nodes oder Cores durch Messungen ermitteln muß.

Cpt. Bucky Saia hat geschrieben:Hey ich verstehs echt nicht oder will es einfach nicht verstehn

Cpt. Bucky Saia hat geschrieben:Herjeh ich weiß ja nichtmal wie ich die Smilys wegbekomme.

Zombie-Bombe
Die Zombie-Bombe ist eine Variante der Fork-Bombe: Bis auf den ersten Prozess der Fork-Bombe
sind alle anderen ein Zombie, also tote Prozesse, die nicht mehr durch Töten beseitigt werden
können, weil sie schon tot sind.
Zombie-Bomben sind im Prinzip etwas schwerer kontrollierbar als einfach Fork-Bomben, weil sie
nur durch Töten des ersten Prozesses (der kein Zombie sein kann) beendet werden können, aber
weil Zombies tote Prozesse sind, steigt die CPU-Auslastung (load average) nicht an und daher
werden laufende Prozesse durch eine Zombie-Bombe kaum beeinträchtigt; ein Rechner kann
dadurch normalerweise nicht zum hängen bleiben (hangup) gebracht werden.
Hier ist ein Beispiel einer Zombiebombe in C, die so lange Zombies produziert, wie geforkt werden
kann:
// zombiebomb.c: A simple zombie bomb.
// "THE BOMBWARE LICENSE" (Revision 22):
// Dr. Rolf Freitag (rolf dot freitag at email dot de) wrote this file.
// As long as you retain this notice you can do whatever
// the GPL (GNU Public License version 3) allows with this stuff.
// If you think this stuff is worth it, you can send me a (deactivated) bomb (or
// money via paypal).
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
int main(int argc, char **argv)
{
pid_t child1;
static long long int lli;
int i_pid = getpid(); // Master PID = first PID
for(;;)
{
lli++;
switch( child1=fork() )
{
case -1 : printf("Error: Could not fork.\n");
continue;
case 0 : // Child: Do remain as a zombie.
printf("Child %lld, PID %d (Master-PID %d)\n", lli, getpid(), i_pid);
exit(1);
default : printf("Parent %lld, PID %d (Master-PID %d)\n", lli, getpid(), i_pid);
continue;
}
}
return 0;
}
Diese ganz einfache Version ist nur eine halbe Bombe, denn die Zombie-Anzahl wächst nur linear,
aber sie erreicht das Limit der Anzahl an Prozessen, das üblicherweise bei ein paar tausend liegt,
nach wenigen Sekunden.
Dann sind aber (zumind. unter SuSE 11.1) keine anderen Forks möglich. Beispielsweise kein login,
egal ob lokal oder remote; man erhält dann die Fehlermeldung "Init: cannot fork, retry..". Damit
kann z. B. ein einfacher User unter SuSE 11.1 verhindern das sich andere User, auch Superuser,
einloggen.
Andere forkende Prozesse, z. B. ein Webserver, der für jede neue Verbindung forkt, werden durch
Zombi-Bomben ebenso beeinträchtigt.
Zombie-Bomben werden wie fork-Bomben verwendet um Limitierungen u. A. zu testen.
Man kann sie auch dazu benutzen um das Forken, also Starten von neuen Prozessen zu verhindern.
Beispielsweise kann man damit das Starten einer (anderen) Fork-Bombe verhindern. Hierzu gibt es
die Analogie ein Feuer durch eine Detonation zu löschen, was beispielsweise bei brennenden Erdölund
Erdgas-Quellen üblich und meist auch das einzig mögliche Verfahren zum Löschen ist.
Analog zur Zombie-Bombe, die die Anzahl der Prozesse bis zum Limit hochtreibt, kann man mit
analogen Bomben auch anderes bis zum Limit hochtreiben, z. B. die Anzahl der Netzwerk-
Verbindungen, den Speicherverbrauch und vieles andere mehr, aber das wirkt sich meist weniger
stark aus als eine Fork- oder Zombie-Bombe.

Zip-Bombe
Eine Zip-Bombe ist eine komprimierte Datei, die unkomprimiert viel größer ist. Dieser Begriff ist
nirgends genau definiert; es ist Ansichtssache ob eine stark komprimierte Datei eine "Zip-Bombe"
ist.
Eine Zip-Bombe ensteht praktisch immer, wenn man ein komprimiertes Image einer fabrikneuen
Festplatte anfertigt, weil sie fast immer nichts (genauer: nur binäre Nullen) enthält.
Ein anderes Beisiel ist 42.zip. Diese Datei enthält 16 gezipte Dateien, die wiederum 16 gezipte
Dateien enthalten, die wiederum 16 gezipte Dateien enthalten, die wiederum 16 gezipte Dateien
enthalten, die wiederum 16 gezipte Dateien enthalten, die je eine Datei von 4,3 GB Größe enthalten,
so dass die Datei nach dem Entpacken 4,5 PByte groß ist. Der Grund für diesen Aufbau ist, das zip
keine Dateien größer 4 GiB verarbeiten kann.
Ein ganz einfacheres Beispiel kann man selber erstellen (Beispiel für Linux/Unix/Cygwin):
dd if=/dev/zero bs=1G count=1024 | bzip2 -9 > klein.bz2
Das Erstellen dieser klein.bz2 dauert rund 11 Stunden mit einem Opteron 8216 (2,4 GHz), weil
bzip2 und dd jeweils nur einen Core auslasten und bzip2 hierbei mit knapp 28 MB/s lahm ist.
Allerdings kann man zum Komprimieren/Dekomprimieren auch Programme nutzen, die mehrere
Cores verwenden und damit um ein Vielfaches schneller sind; beispielsweise Parallel BZIP2.
Die mit 767 kB relativ kleine klein.bz2 ist entpackt 1 TiB groß und enthält genau das, was eine
fabrikneue 1 TiB große Festplatte üblicherweise enthält. Auf ein 2007 mittelmäßig schnelles kleines
RAID, beispielsweise ein RAID0 bestehend aus acht 15k6 SAS-Festplatten, kann diese entpackte
Datei in einer Viertelstunde geschrieben werden und ist dabei noch kleiner als die Anfang 2010
bekannte genaueste Berechnung von Pi: http://www.heise.de/newsticker/meldung/Pi-
Berechnungsrekord-auf-handelsueblichem-PC-899930.html.
Weniger rechenintensiv als die Erstellung mit dd ist natürlich den Header einer komprimierten
Datei zu bearbeiten und so die dekomprimierte Größe einzustellen.
Hier noch eine ähnliche Datei, die mit 2 GiB statt 1 GiB erstellt wurde und die durch die binär
gerade Größe auf nur 102 kB komprimiert wurde: mittel.bz2.
Neben web.de hat man mit solchen völlig ungefährlichen Dateien Probleme auch mit
Virenscannern, beispielsweise Avira AntiVir Personal - Free Antivirus, bei dem man die nervenden
Fehlalarme auch nicht abstellen kann; das Programm ist daher schlicht unbrauchbar.
Der Name der Zip-Bombe entstand durch schlampig programmierte Software, die durch interne
Fehler komprimierte Dateien nicht richtig verarbeitet (siehe nächstes Kapitel und Link) und hat
nichts mit exponentiellem Wachstum zu tun.
Solche Programmierfehlern können ebenfalls zum Hängen bleiben führen unter Anderem bei Hard
Links, Sparse Files, Link Loops (z. B. ln -sf foo bar; ln -sf bar foo) und Directory Loops,
beispielsweise in Zip-Dateien und anderen Dateien die einen Verzeichnisbaum enthalten, wie
beispielsweise ISO-Images. Der Grund für ein mögliches Hängen bleiben ist, das das Expandieren,
also Kopieren als einfache (andere) Datei, sowohl von Hard Links wie von Sparse Files und Link
Loops sowie auch Directory Loops, den Platzbedarf vervielfachen kann und es leicht Probleme gibt,
wenn ein Programmierer dies nicht berücksichtigt.
Open-Source-Source-Software wie z. B. die GNU Core Utilities und direkt von den
Betriebssytemherstellern stammende Programme haben praktisch nie Probleme damit, wie
beispielsweise ein Test mit Link Loops in der Bash zeigt:
> date; ln -sf foo bar; ln -sf bar foo; cat bar; rm bar; rm foo; date
Thu Jul 31 11:49:21 CEST 2008
cat: bar: Too many levels of symbolic links
Thu Jul 31 11:49:21 CEST 2008
>

Bwana Honolulu hat geschrieben:Im Prinzip macht das Ding nichts anderes, als sich selbst aufzurufen (%0 ist ein Verweis aus die laufende Batch-Datei - eine Variable, in der der Name der Datei steht), und zwar zweimal (Das Pipe-Zeichen "|" bindet normalerweise die Ausgabe eines Kommandos an die Eingabe eines anderen, in diesem Fall ist uns das egal, weil nichts ausgegeben wird - hauptsache, das Batchscript wird zweimal ausgerufen).

tarvoc hat geschrieben:Wenn man dem Rechner den Strom abklemmt und dann wieder hochfährt, müsste aber eigentlich wieder alles normal sein, oder?

Sparse-Bombe
So wie eine Zip-Bombe durch Entpacken viel größer werden kann, kann eine Sparse Datei viel
größer sein, als der von ihr belegte Platz auf dem Datenträger, weil sie sozusgen nichts (außer
binären Nullen, wie meist bei Zip-Bomben) enthält und platzsparend, sozusagen transparend
komprimiert, gespeichert wurde. So wie schlampig programmierte Virenscanner an großen
komprimierten Dateien scheitern können, können sie auch an sparsen Dateien scheitern, obwohl sie
keinerlei Code enthalten.
Ein Beispiel für eine sparse Datei ist eine 1 TiB große Datei, die auf dem Datenträger keinen Platz
belegt:
> dd if=/dev/zero of=sparsefile.img bs=1 seek=1T count=0
> du -s sparsefile.img
0 sparsefile.img
> du -B1 --apparent-size sparsefile.img
1099511627776 sparsefile.img
Sozusagen ausgepackt werden Sparse-Bomben auch durch Kopieren mittels "cp --sparse=never".
Deshalb sollte man Kopieren mit cp generell mit der Option -a oder --sparse=always ausführen und
Backups mittels rsync mit -S oder meist besser -avxSH. Allerdings hat rsync, zumind. rsync version
3.0.5, protocol version 30, den Bug das es nur lokal und nicht remote Sparse Dateien als solche
behandelt, so das die Beispiel-Datei in Form von 1 Ti Bytes (=2^(40) Bytes) übertragen wird!
Deshalb gibt es die Beispiel-Datei hier nicht zum Downloaden.
Weil sparse Dateien effizient gespeichert werden, habe ich das Programm dupmerge so erweitert,
das es auch eine Datei durch ihre sparse Version ersetzt, wenn die sparse Version kleiner ist; man
findet dazu Example 1 unter: http://true-random.com/homepage/project ... orial.html.