Sicherheit in vernetzten Systemen - RRZ Universität Hamburg

11.3. GRUNDLAGEN (WIEDERHOLUNG)
entspricht hierbei der in Abbildung 11.1. Neue Variablen werden auf dem Stack beginnend mit hohen
Speicheradressen und zu den niedrigeren Speicheradressen fortschreitend angelegt. Man sagt, daß der
Stack „von oben nach unten“ wächst 10 (auf Abbildung 11.1 in Pfeilrichtung), so daß in unserem Beispiel
der Stackpointer und die Parameter gewissermaßen „über“ dem string buffer liegen, weil diese
vorher dort abgelegt wurden.
bottom of
memory
Stack
buffer sfp ret *str
top of
memory
top of stack
bottom of
stack
Abbildung 11.1: Der Ausführungsstack unter Unix (Beispiel) (nach [Aleph One 1997])
Bei dem in der Funktion enthaltenen strcpy() Befehl wird der Puffer buffer jedoch von unten nach
oben überschrieben, so daß tatsächlich der vom Unterprogramm abgespeicherte Framepointer(sfp),
die Rücksprungadresse(ret), und sogar die Variable *str selbst überschrieben wird.
In der Praxis ist die Folge meistens eine Schutzverletzung (segmentation fault), da bei Beenden des
Unterprogramms versucht wird, die Rücksprungadresse aufzusuchen, die durch zufällig im String
vorhandene Daten überschrieben wurde. Wenn allerdings (z.B. in einer Stringvariable) im Speicher ein
Maschinenprogramm abgelegt wird, das etwa unter Unix eine shell aufruft, und der Puffer gezielt mit
der Adresse dieses Maschinenprogramms überschrieben wird, ist der Effekt deutlich kontrollierter:
Da die Rücksprungadresse der Funktion mit der Adresse eines gültigen Maschinenprogramms überschrieben
wurde, wird nach Beendigung der Funktion die Kontrolle an eben dieses Programm übergeben.
So läßt sich an ein Programm, das diesen Implementierungsfehler 11 enthält, beliebiger Programmcode
übergeben, der dann mit den Rechten des laufenden Prozesses ausgeführt wird. Da unter
Unix einige Prozesse mit den Rechten des Benutzers root laufen, ist dies eine Möglichkeit, sich
unautorisiert root-Rechte auf einem System zu verschaffen.
Es ist wichtig zu bemerken, daß diese Technik nur bei Programmen funktioniert, die auf diese spezielle
Art falsch implementiert wurden. Allerdings bekommt man beim Lesen der Mailingliste bugtraq
(die unter [securityfocus] archiviert wird), den Eindruck, daß dieses Problem auf einen Großteil der
eingesetzten Programme zutrifft. Fast alle gängigen Anwendungen oder Serverprogramme enthalten
oder enthielten zu irgendeiner Zeit ein derartiges Problem 12 .
Wird ein „buffer overrun“ Problem bei einer Software bekannt, schreibt irgendjemand ein Programm,
was diese Sicherheitslücke ausnutzt (im allgemeinen werden solche Programme als „exploits“ bezeichnet).
In der Regel wird das Programm dann auf einer Mailingliste (wie z.B. bugtraq) veröffentlicht,
um zu demonstrieren, daß die Sicherheitslücke ausgenutzt werden kann, aber auch um Administratoren
die Möglichkeit zu geben, zu testen, ob ihr Server verwundbar ist. Die Etikette gebietet
zwar, mit der Veröffentlichung eines „exploits“ zu warten, bis ein Patch für das Problem erhältlich
ist, aber selbst wenn sich daran gehalten wird, bedeutet das noch lange nicht, daß alle betroffenen
10 dieses Wachsen „nach unten“ ist laut [Aleph One 1997] auf vielen Prozessorarchitekturen die Regel.
11 Die Möglichkeit, daß ein Puffer in nicht vom Programmierer beabsichtigter Weise überschrieben werden kann.
12 So z.B. sendmail, syslog, XFree86, wu-ftp, pro-ftp, pine, CDE, die rpc-Suite und viele, viele mehr.
SS 99, Seminar 18.416: Sicherheit in vernetzten Systemen 173