So mancher Admin ist unbeabsichtigt Mitverursacher der eigenen Sicherheitsprobleme, wenn er zu Editor und Compiler greift und Skripte schreibt oder Programme ändert. Dieser Workshop erklärt häufige und gefährliche Fehler im Zusammenhang mit der Prozessumgebung und zeigt, wie es besser geht.
Vom berüchtigten Pufferüberlauf und von Cross-Site-Skripting oder Format-String-Attacken haben die meisten Admins längst gehört. Dicke Bücher widmen sich der Beschreibung von Fehlern und zeigen, wie man sie vermeidet[1],[2]. Anders als vielleicht erwartet ist dieses Know-how aber nicht nur für Software-Entwickler wichtig. Auch und gerade Admins müssen wissen, wie sie sichere Skripte schreiben (unter Zeitdruck) oder beim Ändern von Applikationen typische Fehler vermeiden.
Selbst wenn die Lösung von der reinen Lehre abweicht oder die Effizienz leidet: Sicherheitslöcher darf niemand leichtfertig riskieren[10]. Gelegentlich heißt es sogar: Programm deaktivieren oder selber die Löcher stopfen. Dann muss der Admin beurteilen, was nötig ist und ob ein Patch tatsächlich einen Fehler behebt. Das nötige Hintergrundwissen vermittelt dieser Workshop.
Die Umgebung (Environment), in der ein Programm oder Skript abläuft, ist ein verblüffend komplexes Gebilde. Sie enthält Umgebungsvariablen, das Arbeitsverzeichnis, Rootverzeichnis, Rechte, Ressourcenlimits, Umask, File-Deskriptoren, Signalhandler und einiges mehr. Gelingt es einem Angreifer, die Umgebung fremder Prozesse gezielt zu beeinflussen, droht Gefahr. Vorsicht ist vor allem geboten, wenn Programme mit gesetztem Set-UID-Bit laufen.
Privilegierte Prozesse bieten eine besonders große Angriffsfläche. Saboteure manipulieren eventuell schon den Programmstart, um die Software in einer unerwarteten Umgebung laufen zu lassen. Beim Start erbt der Prozesses das Environment seines Vaterprozesses, auch Shell und Kernel nehmen darauf Einfluss. Viele Charakteristika stammen indirekt aus dem übrigen System, zum Beispiel der verfügbare Speicher oder der Aufbau der Dateisysteme (siehe Abbildung 1).
Das kleine Linux-Werkzeug Env_audit[3] stellt viele Eigenschaften eines Prozesses in lesbarer Form dar. Der Kasten "Umgebungs-Audit" erläutert die Installation und Anwendung des Tools. Listing 1 zeigt die Ausgabe von »env_audit«, das unter der Standardinstallation eines Apache 1.3.26 auf Debian Woody 3.0r2 als CGI-Skript lief.
Die Zeilen 3 bis 12 informieren über die Prozessverwaltung und die Rechte. Die CGI-Skripte arbeiten unter der User- und der Gruppenkennung »www-data«. Das hat recht unangenehmen Konsequenzen, wenn der Server die Präsenzen mehrerer Kunden hostet, die CGI-Skripte installieren dürfen. Dann könnten die Prozesse des einen Kunden denen der anderen Signale schicken, etwa »kill -9«, den fremden Arbeitsspeicher über das »/proc«-Dateisystem einsehen oder temporäre Dateien manipulieren.
Laut Zeile 14 verzichtet die Umask darauf, bei neu erzeugten Dateien die Leserechte anderer Benutzer einzuschränken. Skripte, die mit Geheimnissen hantieren, sollten das beachten und ihre Umask auf einen sicheren Wert setzen. Ab Zeile 18 listet Env_audit die Umgebungsvariablen. »PATH« sieht vernünftig aus - Apache hat einen Standardwert benutzt. Das ist oft wichtig, damit ein Angreifer kein ».« einschmuggelt.
Neben »PATH« ist die »IFS«-Variable besonders gefährlich. Sie enthält die Zeichen, an denen die Shell einzelne Wörter auf der Kommandozeile trennt. Meist sind das Leerzeichen, Tabulatoren und Zeilenumbrüche. In Zeile 46 warnt Env_audit, dass IFS gar nicht gesetzt ist.
Abbildung 1: Die Umgebung eines Prozesses führt interne Eigenschaften wie Umask oder UID auf sowie Schnittstellen zur Umgebung - von Umgebungsvariablen bis zur Ein- und Ausgabe. Auch das übrige System wirkt sich auf einen Prozess aus.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
