PHP-Sicherheit: Vorsicht vor popen() und proc_open()

Seit einigen Tagen stellen verschiedene Provider einen deutlichen Anstieg gehackter Kundenpräsenzen ("Defacements") und installierter Hintertüren auf vielen Webservern fest.

Die offenbar zielstrebig vorgehenden Angreifer nutzen dabei eine Vielzahl bekannter Sicherheitslücken aus, die zwar größtenteils nicht neu und auf fachkundig administrierten Servern in der Regel auch abgesichert und deaktiviert sind. Dabei ist vor allem vor den Auswirkungen der PHP-Funktionen popen() und proc_open() zu warnen, die bislang ein unbekanntes Schattendasein führten.

In den Angriffen der vergangenen Tage wurden diese Funktionen gezielt ausgenutzt, ermöglichen sie doch ebenfalls den Start lokaler Shell-Kommandos auf dem Server. Sichert eine Webseite die Nutzung dieser Funktionen nicht richtig ab, kann ein Angreifer damit eigene Kommandos ausführen oder gar eigene Hintertüren installieren. Beim Einsatz so genannter Bots verbinden sich diese mit IRC-Servern, um Kommandos des Angreifers entgegenzunehmen. Die so infizierten Server lassen sich damit flexibel zu beliebigen Aktionen missbrauchen.

Zugriffe auf das Dateisystem eines Webservers sind allgemein ein großes Problem und werden fachkundig mittels open_basedir abgesichert. Der Start von Shell-Kommandos in PHP-Scripts ermöglicht es Angreifern, diese Beschränkungen zu umgehen, sodass sie Leserechte auf weite Teile des Dateisystems erhalten: Außer Systemdateien des /etc-Verzeichnisses sind auch temporäre Dateien mit Session-Informationen fremder Nutzer einsehbar. Von anderen Webpräsenzen auf demselben Server sind die Passwörter der .htpasswd-Dateien beziehungsweise MySQL-Zugangsdaten einsehbar.

Pikanterweise sind die Probleme nicht neu. Anders als bei system() und exec() hat das PHP-Team es jedoch in der Vergangenheit versäumt, vor popen() und proc_open() ausreichend zu warnen. Auf den Handbuchseiten der jeweiligen Funktionen finden sich keine Warnungen, auch bei der Besprechung verschiedener Sicherheitsstrategien im Manual des PHP-Projektes werden system(), exec() oder phpinfo() erwähnt – der Verweis auf proc_open() und popen() fehlt aber in aller Regel.

Aufgrund der geringen Bekanntheit haben nur wenige Hobby-Programmierer bislang diese Funktionen benutzt, allerdings kommen sie zum Beispiel bei den weit verbreiteten Projekten mediaWiki und eGroupware zum Einsatz. Nach ersten Tests scheint eine Deaktivierung von popen() allerdings nur geringe Auswirkungen auf die Funktion dieser Programme zu haben, grundsätzlich bleiben sie lauffähig.

Sofern Programmierer saubere Eingabevalidierung betreiben und popen()-Aufrufe nur mit sicheren Parametern benutzen, droht dem Webserver keine Gefahr eines Angriffes von außen. Verarbeiten Programmierer jedoch ungefiltert Nutzereingaben in diesen Funktionsaufrufen, können Angreifer beliebige eigene Kommandos einschleusen, wie jüngst beim CMS open-medium geschehen. Nicht zuletzt könnten Angreifer gezielt versuchen, sich einen Account bei einem Provider zu besorgen, um eigenen PHP-Code bequem selbst hochzuladen.

Administratoren sollten also versuchen, diese Funktionsaufrufe durch den Eintrag

disable_functions = show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open

in der Datei php.ini zu verbieten, müssen dann jedoch kritisch beobachten, ob Funktionsstörungen bei Kundenpräsenzen auftreten.

Das frei verfügbare AppArmor mit dem Apache-Modul mod_changehat könnte eine Lösung sein: Es ermöglicht es, für einzelne Webpräsenzen verschiedene AppArmor-Profile zu übergeben, die den Dateizugriff auch bei externen Programmaufrufen kontrollieren können.

Peer Heinlein, Geschäftsführer der Firma Heinlein Support in Berlin (hb)