30.2 Typische Schwachstellen bei PERL Skripten
- Die Ausführung externer Kommandos (sei es durch system() oder auch ganz
einfach bei einer Pipeline mit open()) ist grundsätzlich sehr gefährlich, wenn
eine Angreifer auf die Übergabeparameter Einfluß nehmen kann.
- Wenn bei auszuführenden Kommandos kein absoluter Pfadname angegeben wird,
kann es "Überraschungen" durch eine manipulierte Umgebungsvariable PATH, IFS
... geben oder durch vorgeschobene Kommandos eines Angreifers, die weiter vorne
im Pfad vor dem eigentlich gewünschten Kommando liegen.
- Sowohl bei open() als auch bei system() sind beliebige Shell-Metazeichen
zugelassen. Wenn eine Einflüßmöglichkeit auf die Zeichenkette existiert, die
der Shell übermittelt wird, ist es damit leicht möglich, ein Kommando des
Angreifers anzuhängen, z.B. ; rm -rf /, welches die Festplatte
löscht.....
- Die Shell trennt Kommandozeilen auf Basis der Umgebungsvariablen IFS auf.
Wenn die z.B. auf den Schrägstrich gesetzt wird, dann wird aus einem
absoluten Kommandonamen beispielsweise unerwartet das Kommando usr.
- Wenn Dateien zum Schreiben eröffnet werden:
- wenn der Dateiname in Abhängigkeit von Angaben eines Angreifers gewählt
wird,
- die zu kreierende Datei in einem vom Angreifer beeinflußbaren Verzeichnis
liegt, oder
- wenn der Dateiinhalt beeinflußt werden kann.
- 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.
- 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ß.
- Natürlich sind auch viele weitere Systemaufrufe gefährlich wie z.B. mkdir,
chmod, chown usw.
- 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.
- 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.
- Weitere Probleme kann es mit (ansonsten überprüften)
Kommandozeilenargumente geben, die zu lang sind.
- 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.
- Häufig werden solche Sicherheitsaspekte bei Hilfsprogrammen nicht beachtet,
da sie alleine genommen kein Sicherheitsrisiko darstellen.
![[Inhalt]](toc.gif)