Stefan Esser, Security Consultant und Entwickler von Hardened PHP, erklärt im zweiten Teil des InfoWeek-Interviews, weshalb Santy Anfang Jahr so viele Server über verwundbare phpBB-Installationen angreifen konnte und wie sich die Sicherheit der Scriptsprache PHP verbessern lässt.
InfoWeek: Beim Santy-Wurm, der Anfang dieses Jahres Server
über phpBB- Installationen angegriffen hat, hat man gesehen,
dass die meisten Provider ihre
Server nur unzureichend gesichert haben. War das für Sie eine Überraschung?
Oftmals werden Konfigurationsdirektiven wie safe_mode oder allow_url_fopen als verlässliche Schutzmechanismen angesehen. Trotzdem können noch viele Scripte angegriffen werden. Weshalb?
Weder der safe_mode noch allow_url_fopen waren ursprünglich dazu gedacht, Skripte gegen Angriffe von aussen zu schützen. Beide Direktiven limitieren nur die Funktionalität von PHP.
Der safe_mode steuert den Zugriff auf Dateien, und allow_url_fopen schaltet den Zugriff auf Remote URLs aus. Das grosse Problem hierbei ist, dass PHP gegen sehr viele externe Bibliotheken gelinkt wird und diese zum Teil Funktionalitäten anbieten, mit denen an PHP vorbei auf Dateien zugegriffen werden kann. Der Schutz vom safe_mode ist daher wirkungslos, und deshalb wird der safe_mode wahrscheinlich mit PHP 6 komplett verschwinden. «Allow_url_fopen hat hingegen den falschen Namen. Eigentlich verbietet diese Direktive nur den Aufruf von URLs, die dazu führen würden, dass der Server eine Verbindung nach aussen aufbaut. Sie verbietet aber nicht den Zugriff auf URLs, die keine separate externe Verbindung aufbauen müssen, deren Inhalt aber dennoch von aussen stammt. Ein Beispiel wäre php://input. Zusätzlich sind viele der veröffentlichen Lücken in Webapplikationen SQL-Injection- oder Cross-Site-Scripting-Lücken, und diese beide Klassen werden von den beiden Direktiven gar nicht berührt.
Wie gefährlich ist der automatische Import von Request-Variablen (register_globals) wirklich?
Für eine sauber programmierte Applikation ist register_globals nicht gefährlich, da man dort eher wenige globale Variablen benutzt und diese ordnungsgemäss initialisiert. Nur sind viele PHP-Skripte leider nicht so sauber programmiert, wie man sich das wünschen würde, und daher wird hier und da die Initialisierung einer Variablen komplett vergessen. Daher weiss der Programmierer gar nicht, dass es so etwas wie register_globals gibt, weil immer gepredigt wird, dass man dieses Feature tunlichst ausschalten sollte, und daher gar nicht weiss, dass er unbedingt alle Variablen initialisieren sollte. In diesem Fall kann ein Angreifer von aussen die Variablen nach seinem eigenen Gutdünken vorbelegen. Bei der letzten Wordpress-Lücke hatte dies zur Folge, dass man von aussen bestimmen konnte, wie Eingaben gefiltert und welche PHP-Funktionen dazu ausgeführt werden sollen.
Die PHP-Entwickler denken darüber nach, im Rahmen von PHP 6 register_globals wie auch magic_quotes_gpc endgültig zu entfernen und durch eine Filter-Extension zu ersetzen. Ein sinnvoller Schritt?
Zunächst einmal wurden diese Änderungen bisher nur zwanglos vorgeschlagen, und die PHP-Entwickler bedauern, dass diese Diskussion sofort in diversen Blogs und auch auf Newssites wiederzufinden war. Man muss sich bewusst sein, welche Konsequenzen diese Änderungen haben. Wird zum Beispiel magic_quotes_gpc entfernt, dann sind plötzlich alle alten Skripte unsicher, die davon ausgehen, dass magic_quotes_gpc eingeschaltet ist. Dies ist leider sehr häufig der Fall. Entfernt man andererseits register_globals, dann wird dies zur Folge haben, dass neue PHP-Programmierer nur noch Skripte schreiben, die register_globals gar nicht kennen. Dies wird dazu führen, dass Variablen nicht mehr sauber initialisiert werden. Wenn man nun solch ein Skript auf einem Server mit einer älteren PHP-Version nutzt, ist es sehr wahrscheinlich angreifbar.
Ob die Filter-Extension sinnvoll sein wird, bleibt abzuwarten. Es gibt bisher nur Vorschläge, was die Extension am Ende können soll. Es herrscht darüber noch keine Einigkeit, und wenn es darauf hinausläuft, dass die meisten Applikationen diese Funktionalität gar nicht nutzen, dann wurde dadurch nichts gewonnen.
Sie entwickeln mit Hardened-PHP bereits seit einiger Zeit einen Patch für PHP, mit dessen Hilfe Server besser gegen die Programmierkünste der User geschützt werden können. Als wie wirkungsvoll erweist sich Ihr Projekt ?
Der Hardening-Patch erweist sich in der Realität als sehr wirkungsvoll. Davon abgesehen, dass während seiner Entwicklung schon diverse Male Sicherheitslücken in PHP aufgedeckt wurden, hat insbesondere der Schutz vor URLs in den Dateinamen von Includes schon zur Aufdeckung von Sicherheitslücken in Firmenwebseiten geführt, die von einem der automatischen Robots attackiert wurden, welcher nach genau diesen Lücken sucht, indem er jeden Parameter durchprobiert. Auf diese Weise wurden zum einen die Firmen selber vor dem Eindringen des Wurms geschützt und gleichzeitig wurde die Position der jeweiligen Lücke durch die Einträge im Log enthüllt. Darüber hinaus wird eine ganze Reihe von möglichen Fehlerklassen komplett eliminiert und daher lässt sich eine gewisse Wirksamkeit nicht abstreiten.
Könnte eine Integration von Hardened PHP oder anderer Funktionen wie die von Runkit bereitgestellte Sandbox oder ein Perl-ähnlicher Taint Mode in die Standard-Installation von PHP die Probleme mit schlecht programmierten Applikationen entschärfen?
Es kann durchaus sein, dass einige Teile vom Hardening-Patch in PHP 6.0 integriert werden. Dies wurde auch bereits diskutiert.
Eine Sandbox ist ja im Grunde nichts anderes als ein eval()-Statement, welches diverse Funktionen und Variablen nicht nutzen darf. In den meisten Fällen, in denen eval() genutzt wird, ist es sowieso überflüssig, und daher wäre auch eine Sandbox nicht nötig. Ausserdem müssten natürlich alle Skripte in der Art abgewandelt werden, dass sie die Sandbox-Funktionalität überhaupt nutzen. Es würde also keinen Vorteil für bereits programmierte Applikationen bringen. Ein PHP-Taint-Mode könnte hingegen eine ganze Reihe von Problemen lösen. Dabei muss allerdings beachtet werden, dass es ein ausserordentlich grosser Aufwand sein wird, alle Schlupflöcher zu finden und zu schliessen. Zusätzlich bedeutet ein Taint Mode eine verlangsamte Ausführung des Programmcodes. In der Entwicklerversion des Hardening-Patches existieren bereits erste Anfänge einer Implementierung, doch lässt sich der Nutzen erst nach Abschluss der Entwicklung ermitteln.
Existieren weitere sinnvolle technische Möglichkeiten, mit denen sich Server schützen lassen?
Wenn es möglich ist, sollten Applikationen stets isoliert voneinander installiert werden. Damit ist gemeint, dass sie möglichst auf unterschiedlichen Servern liegen, auf verschiedene Datenbanken zugreifen oder zumindest unter verschiedenen Benutzerrechten operieren und dass diese Server in einem BSD-Jail oder einem Chroot-Bereich liegen. Für letzteres existiert zum Beispiel das Apache-Modul mod_chroot. Auf diese Weise lässt sich ein Einbruch eindämmen. Ich empfehle natürlich zusätzlich die Installation des PHP- Hardening-Patches, weil dadurch Lücken wie Remote URL Includes nicht mehr ausgenutzt werden können. Um sich gegen Lücken im Webserver selber zu schützen, ist die Installation von Grsecurity empfehlenswert. Wovon ich Einsteigern immer abrate, ist der Einsatz von mod_security. Mod_security ist eine Web Application Firewall, die es erlaubt, gewisse Anfragen anhand von Signaturen abzublocken. Das Problem von mod_security ist hierbei, dass zum einen die verwendeten Signaturen und zum anderen das Modul selber aufgrund von Lücken umgangen werden können und es den Leuten, die es nutzen, vorgaukelt, ein verlässlicher Schutz zu sein, dabei würde ich es eher als ein grobmaschiges Sieb betrachten.
Für viele Entwickler ist es schwierig, Sicherheitslücken zu erkennen oder zu vermeiden. Wie kann man den eigenen Blick dafür schulen?
Man sollte sich zunächst einmal darüber informieren, was für Typen von Sicherheitsproblemen in Webapplikationen existieren. Dabei hilft oftmals allein die Internet-Suche nach Schlagwörtern wie SQL Injection oder Cross Site Scripting. Teilweise werden diese Probleme auch im Sicherheitsabschnitt des PHP-Manual beschrieben. Zusätzlich kann man sich unter anderem die Bücher des dpunkt Verlags (siehe «Buchtips») zulegen. Dort werden die Probleme und ihre Lösungen detailliert mit Beispielen beschrieben. Ich empfehle dabei aber stets, Beispiele nicht 1:1 zu übernehmen, sondern an diesen zu prüfen, ob man das jeweilige Problem verstanden hat, damit man es dann selbst implementieren kann. Ein Kursprogramm von unserer Seite ist ebenfalls in Arbeit.
Was können Firmen tun, die auf PHP-Software zurückgreifen und sich um die Sicherheit sorgen?
Beim Einsatz von Applikationen, und dabei meine ich nicht nur PHP- Software, ist es generell ratsam, sich den Security Track Report auf Seiten wie Security Focus anzuschauen. Dabei bekommt man vielleicht ein Gefühl dafür, wie schnell die Entwickler Sicherheitslücken stopfen, wie viele es bislang gab und wie seitens des Projekts grundsätzlich damit umgegangen wurde. Darüber hinaus sollte man stets die Server mit den bereits erwähnten Methoden absichern, damit ein Einbrecher möglichst wenig Schaden anrichten kann. Zudem sollten Security-Mailinglisten abonniert und die Projektseiten regelmässig besucht werden, damit man schnellstmöglich von neuen Updates erfährt. Und letztendlich kann man natürlich einen Audit der Applikation beziehungsweise des Servers zum Beispiel beim Hardened PHP-Project buchen.
