Du kommst da net rein: Dieser Spruch selbstgefälliger Türsteher ist bei sicherer Software unvermeidbar. Jedes Programm muss genau wissen, welche Daten zu ihm passen und welche es ablehnt. Die guten von bösen Eingaben unterscheiden fällt aber nicht immer leicht.

Software, die sinnvolle Arbeit verrichtet, bezieht fast unweigerlich Eingaben von Anwendern, anderen Programmen, aus dem Netz oder aus dem lokalen System. Die üblichen Datenpfade sind Argumente der Kommandozeile, Dateien, Eingaben von Maus und Tastatur, Signale und vieles mehr. Manche Programme erhalten ihre Eingaben bereits beim Start, andere erst, während sie laufen. Die erste Folge dieses Workshops [1] hat sich unter anderem mit überraschenden Eingaben beim Programmstart beschäftigt; dieser Teil geht näher auf die Sicherheitsfolgen der erwünschten und unerwünschten Eingaben ein.

Wie ernst diese Gefahren sind, bestätigt ein Blick auf einschlägigen Sicherheitsseiten. Bei Securitytracker [8] füllen die so genannten Boundary Errors eine ganze Kategorie (siehe Abbildung 1). Meist mehrmals pro Tag ergänzen die Betreiber neue Sicherheitslücken in dieser Fehlerklasse.

Wie schnell solche Fehler passieren, zeigt das einfach gestrickte Programm »patch-fstring« in Listing 1. Es schreibt in einer vorhandenen Datei an eine bestimmte Stelle eine Zeichenkette und verlangt dafür auf der Kommandozeile vier Argumente: den Dateinamen, eine Blockgröße und -nummer und als Letztes den Korrekturstring. Die Position, an der das Patchprogramm den String einfügt, berechnet es aus Blockgröße mal Blocknummer.

Beispiel: Files patchen

In den Zeilen 8 bis 11 (Listing 1) speichert der Code seine Aufrufargumente in eigenen Variablen. Dann öffnet das Programm die Datei mit »fopen()« (Zeile 13), berechnet die Position (Zeile 17) und spult den Dateizeiger mit »fseek()« zur gewünschten Stelle vor (Zeile 18). Abschließend schreibt »fprintf()« in Zeile 21 die Daten in die Datei.

Dieser unscheinbare Code steckt trotz seiner Kürze voller Probleme:

• Es ist nicht sicher, dass der Aufrufer wirklich vier Argumente
  übergibt, er könnte das Programm auch mit
  »patch-fstring foo 1 2« starten.
• Die Ascii-to-Integer-Funktion »atoi()« liefert 0,
  wenn sie ihre Eingabe nicht als Zahl erkennt (Zeilen 9 und 10;
  Aufruf etwa mit »patch-string foo 0x100 10
  hallo«).
• Bei der Multiplikation großer Zahlen kann es zu einem
  Integerüberlauf kommen (»patch-fstring foo 1000000 8000
  hallo«).
• Der »fprintf()«-Aufruf ist zudem anfällig
  für Formatstring-Angriffe, wenn der Benutzer Prozentzeichen
  eingibt (»patch-fstring %n%n%n 0 0 0«) [7].

Die ersten drei Anwendungsfehler führen eventuell dazu, dass das Patchprogramm die Schreibposition falsch berechnet. Der String landet dann irgendwo und die Datei ist im Eimer (Abbildung 2).

Ursachen

Fehler durch Eingaben haben immer dieselbe Ursache: Ein Programm akzeptiert Daten, mit denen es nicht umzugehen weiß. Es genügt, wenn ein einzelner Wert nicht in den gewünschten Wertebereich passt. Patch-fstring findet zum Beispiel nichts Anrüchiges an der unsinnigen Blockgröße -23. Oder eine Kombination von Eingabedaten sprengt den erlaubten Rahmen, etwa eine Datumsangabe wie 29.2.2007. Für sich genommen sind alle drei Werte (29, 2 und 2007) erlaubt, nur ist 2007 kein Schaltjahr.

Ursachen sind Faulheit, Naivität, Zeitmangel oder fehlende Übersicht über die Zusammenhänge. Der verführerische Gedanke "Da muss der Benutzer eben aufpassen" erspart dem Entwickler zwar viel Aufwand. Dummerweise überlässt er damit die Sicherheit leichtfertig dem Anwender. Der vertippt sich aber gelegentlich, versteht die Anleitung nicht oder gehört gar zu den bösen Buben. Oder er zeigt das Programm dem Kollegen aus der Nachbarabteilung, der es zum frei zugänglichen CGI-Skript umfunktioniert - nicht ahnend, welche Lücke er damit aufreißt.

Du kommst da net rein: Dieser Spruch selbstgefälliger Türsteher ist bei sicherer Software unvermeidbar. Jedes Programm muss genau wissen, welche Daten zu ihm passen und welche es ablehnt. Die guten von bösen Eingaben unterscheiden fällt aber nicht immer leicht.