Open Source im professionellen Einsatz
Linux-Magazin 04/2005

Workshop: Sicheres Programmieren für Administratoren - Folge 2

Wurzelbehandlung

Fast jedes Skript oder Programm öffnet und bearbeitet Dateien. Dieser Workshop zeigt, wo die Gefahren lauern, und erklärt Admins und Entwicklern, wie sie Fehler schon an der Wurzel neutralisieren.

319

Zahlreiche Fallen für den programmierenden Admin verbergen sich in ganz unschuldig aussehenden Dateioperationen, etwa ein File erzeugen, öffnen oder schließen. Teil 1 dieser Serie[1] hat bereits offene Dateien bei Programmstart und -ende behandelt; diese Folge gibt Hinweise, wie man weitere Operationen auf dem Dateisystem mit C, C++ und Shellskripten zähmt.

Die Wurzel des Übels

Unix ordnet Dateisysteme, Geräte und andere Ressourcen unterhalb des Wurzelverzeichnisses in einen Verzeichnisbaum ein, auf den viele Prozesse gleichzeitig zugreifen dürfen. Diese Parallel-Zugriffe führen oft zu so genannten Race Conditions, die sich als Sicherheitslücke manifestieren (siehe Kasten "Symlinks, Races und deren Folge").

Listing 1:
Symlink-Schwäche

01 #!/bin/sh
02 for i in `find . -name "*.txt"`; do
03         tr "A-Z" "a-z" < $i > /tmp/unsicher.tmp
04         mv /tmp/unsicher.tmp $i
05 done

Race Conditions treten ein, wenn ein Programm oder Skript davon ausgeht, dass sich seine Umgebung nicht verändert. Während er mit Dateien hantiert, kann ein Prozess aber allerlei Überraschungen erleben: Zwischen zwei Einzelaktionen erzeugt vielleicht ein anderer Prozess eine neue Datei oder ein Verzeichnis, löscht oder verschiebt es, der Admin hängt ein Dateisystem ein oder aus (»mount()«, »umount()«), ändert den Besitzer einer Datei, ein Benutzer hängt einen symbolischen Link um, erzeugt oder löscht einen Hardlink oder ändert die Rechte einer Datei.

Namensfrage

Verwundbar sind vor allem Programme und Skripte, die sorglos mit Dateinamen werkeln. Kein gängiges Dateisystem garantiert, dass ein Name sich zu zwei verschiedenen Zeitpunkten auf denselben Inode bezieht. Dabei riskiert der Programmierer dreierlei:

  • Er operiert mit einer anderen Datei als beabsichtigt.
  • Eigenschaften der Datei ändern sich unerwartet.
  • Ein Benutzer oder ein Prozess erhält andere Zugriffsrechte
    als gewollt.

Ganz zu verhindern sind solche Pannen auch nicht durch scharfe Sicherheitsmaßnahmen, doch sollte der Entwickler sein Programm darauf vorbereiten. Bei der Abwehr darf er immerhin davon ausgehen, dass Root gefährliche Situationen nicht absichtlich herbeiführt.

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Identitätskrise

    Nur weil sich ein Programm besonders paranoid verhält, ist es noch lange nicht sicher: Das recht bekannte Perl-Programm Ridentd verschleiert zwar aufwändig die Identität eines Users, leidet aber an Sicherheitslücken. Welche das sind und was Programmierer dagegen unternehmen, zeigt dieser Artikel.

  • Red Hat: Symlink-Attacke durch Sudo-Paket
  • Gesichtskontrolle

    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.

  • Airbag für den Webserver

    Wenn Benutzer beliebige PHP-Skripte installieren, gefährden sie die Sicherheit des Webservers. Kleine Fehler genügen, um Angreifern Zugang zum Dateisystem oder zur Shell zu geben. Doch dem Admin bleibt ein Schutzschild: Nutzt er die Optionen von PHP konsequent, ist das Risiko erträglich.

  • Ruby: Minitar erlaubt Directory-Traversal-Attacke
comments powered by Disqus

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.