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)