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


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



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

    Die offensichtlich 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 die Webseite die Nutzung dieser Funktionen nicht ordnungsgemäß ab, so kann ein Angreifer damit eigene Kommandos ausführen oder gar Hintertüren installieren. Beim Einsatz sogenannter 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 ja allgemein ein großes Problem und werden fachkundig mittels open_basedir abgesichert. Der Start von Shell-Kommandos in PHP-Scripts ermöglicht es aber den 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 doch recht geringen Bekanntheit haben nur wenige Hobby-Programmierer bislang diese Fuktionen benutzt, allerdings kommen sie zum Beispiel bei den weit verbreiteten Projekten mediaWiki und eGroupware dennoch zum Einsatz. Nach diversen Tests scheint eine Deaktivierung von popen() allerdings nur sehr geringe Auswirkungen auf die Funktion dieser Programme zu haben, grundsätzlich bleiben sie aber lauffähig.

    Sofern Programmierer saubere Eingabevalidierung betreiben und popen()-Aufrufe nur mit sicheren Parametern benutzen, droht dem Webserver auch 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 sogar 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.

    Quelle: heise