Firewall Handbuch für LINUX 2.0 und 2.2 - zurück

5. Wenn Dateien zum Schreiben eröffnet werden:
1. wenn der Dateiname in Abhängigkeit von Angaben eines Angreifers
gewählt wird,
2. die zu kreierende Datei in einem vom Angreifer beeinflußbaren
Verzeichnis liegt, oder
3. wenn der Dateiinhalt beeinflußt werden kann.
6. Eine typische Falle kann hier die Mächtigkeit von open() darstellen. Während
open(OUT, $filename) recht harmlos aussieht, wird dies zum idealen
Angriffspunkt, wenn beispielsweise $filename am Ende ein Pipeline-Zeichen
erhalten kann oder wichtige Systemdateien (wie z.B. /etc/passwd) bedroht
werden können.
7. Selbst wenn auf $filename kein Einfluß ausgeübt werden kann, kann das
Anlegen temporärer Dateien in öffentlichen Verzeichnissen (z.B. /tmp) zur
tödlichen Falle werden, wenn dort der Angreifer zuvor einen symbolischen
Verweis auf /etc/passwd für den zu erwartenden Dateinamen hinterließ.
8. Natürlich sind auch viele weitere Systemaufrufe gefährlich wie z.B. mkdir,
chmod, chown usw.
9. Perl selbst ist zwar immun gegen den Hauptangriffspunkt bei in C
geschriebenen Programmen auf Basis von Puffer-Überläufen, jedoch sind
möglicherweise in C geschriebene Programme oder hinzugeladene
Bibliotheken bedroht.
10. Typische Fallen sind hier Umgebungsvariablen (z.B. HOME), die auf extrem
lange Werte gesetzt werden und damit aufgerufene Shells zur Ausführung mit
übergebenen Codes des Angreifers bringen können (diese Technik ist als
stack smashing bekannt). Weitere Kandidaten sind die Umgebungsvariablen
USER oder LOGIN, bei denen häufig naive Annahmen über deren maximale
Länge gemacht wird.
11. Weitere Probleme kann es mit (ansonsten überprüften)
Kommandozeilenargumente geben, die zu lang sind.
12. Auch Eingaben, die über eine Pipeline an ein fremdes Programm erfolgen,
können einen Angriffspunkt darstellen, wenn z.B. gets statt fgets auf der
einlesenden Seite verwendet wird.
13. Häufig werden solche Sicherheitsaspekte bei Hilfsprogrammen nicht
beachtet, da sie alleine genommen kein Sicherheitsrisiko darstellen.
30.3 Lösungsmöglichkeiten
1. Bei Skripten mit s-bit sind grundsätzlich alle Umgebungsvariablen mit
äußerster Vorsicht zu behandeln, wenn irgendwelche Kommandos oder
Pipelines gestartet werden. Insbesondere sind PATH und IFS neu zu setzen
und alle anderen Umgebungsvariablen sollten in ihrer Länge begrenzt
werden.
2. Jeder Systemaufruf open() und jeder Aufruf von system() sollten ganz genau
daraufhin untersucht werden, inwieweit hier Abhängigkeiten von den
Eingaben eines Angreifers vorliegen.
3. Temporäre Dateien sollten in privaten Verzeichnissen angelegt werden, die
für niemanden sonst zugänglich sind oder es sollte mit O_EXCL und
O_CREAT gearbeitet werden (dies empfiehlt sich übrigens generell!).
4. Generell sollte überprüft werden, welche Privilegien tatsächlich wie lange
notwendig sind:
1. Es ist möglicherweise sinnvoll, den Prozeß (ggf. ab einem
bestimmten Zeitpunkt) oder einen Kindprozeß unter einer chroot-
Umgebung oder unter einer Benutzerberechtigung laufen zu lassen,
die nur sehr wenig Rechte gibt.
2. Ein Prozeß, der mit der Außenwelt in Verbindung steht, kann unter
sehr restriktiven Bedingungen laufen und alle gefährlichen
Operationen an einen weiteren Prozeß mit normalen Privilegien
Erstellt von Doc Gonzo - http://kickme.to/plugins