Löcher, gross wie Scheunentore, über die sich ohne grossen Aufwand in Server einbrechen lässt, klaffen regelmässig in populärer PHP-Software. Kaum ein PHP-Script ist nicht für Cross-Site-Scripting und das Einschleusen von schadhaftem Code verwundbar. Dieses Bild erhält man, wenn man in der letzten Zeit Security-Advisories liest und sich bei einigen Webhostern umhört. Entsprechend leidet das Image der freien Scriptsprache PHP. Doch stimmt dieses Bild wirklich mit der Realität überein? InfoWeek hat mit Stefan Esser, Security Consultant und Experte für PHP-Sicherheit, über die aktuelle Situation gesprochen und nach Ursachen und Lösungen gefragt.
InfoWeek: Wenn man die Security-Advisories auf Bugtraq der letzten Tage und Wochen durchliest, findet man aussergewöhnlich oft das Wort PHP, teilweise sogar mehrmals täglich. Steht es wirklich so schlecht um die Sicherheit von PHP-Applikationen?
Stefan Esser: Es ist richtig, dass PHP-Applikationen in letzter Zeit sehr häufig auf Bugtraq erwähnt werden. Doch muss man dabei bedenken, dass es oft die gleichen Applikationen sind, in denen
immer und immer wieder Lücken gefunden werden, weil sie einfach unsauber programmiert sind und eigentlich einer komplette Neuprogrammierung bedürften. Zum
anderen muss man sich vor Augen halten, dass andere Skriptsprachen bei weitem nicht an die Installationsbreite und Anwendungsbreite von PHP herankommen. Da um
ein Vielfaches mehr PHP-Applikationen existieren, ist es auch nicht verwunderlich, dass es um ein Vielfaches mehr an Security Advisories gibt. Einige der alternativen Technologien sind nur in Einzelfallanwendungen verbreitet, und solange diese Applikationen nicht breitflächig genutzt werden, ist es recht unwahrscheinlich, jemals ein Security Advisory dafür auf Bugtraq zu finden.
Andererseits kursiert auch die Theorie, dass die Sicherheitsprobleme von PHP selbst verursacht werden. Kritiker behaupten, PHP lade gerade dazu ein, Sicherheitslöcher zu programmieren.
Beschränkt man sich auf die Register-Globals-Problematik und die Tatsache, dass Variablen in PHP nicht initialisiert werden müssen, kann man dieser Aussage zum Teil zustimmen. Allerdings ist die Aussage ansonsten nicht sehr zutreffend, da die übrigen Lücken nicht wirklich PHP-spezifisch und in nahezu jeder eingesetzten Technologie anzutreffen sind. Eine Ausnahmestellung mögen hierbei noch die URL Includes einnehmen. Aber im Endeffekt fallen auch diese darauf zurück, dass der Programmierer ungeprüft Benutzereingaben an «gefährliche» Funktionen weitergibt. Und eigentlich gebietet schon der gesunde Menschenverstand, dass man die Quelle für den auszuführenden Code in keinster Weise von aussen vorgeben lassen sollte.
Welche Rolle spielt für Sie die teils mangelhafte bis gar nicht vorhandene Behandlung von Sicherheitsaspekten in Publikationen zum Thema PHP, insbesondere in Einsteiger-Büchern?
Fehlende Aufklärung der Programmierer und insbesondere der Einsteiger über die möglichen Gefahren beim Einsatz von gewissen Funktionen ist einer der Hauptgründe für Sicherheitslücken in den Applikationen. Beispiele werden aus Publikationen oftmals 1:1 kopiert, ohne dass die Anwender diese genau verstehen. Das Problem wird noch dadurch verschärft, dass die Beispiele meistens um wichtige Sicherheitsabfragen gekürzt sind. Mir sind einige Fälle bekannt, wo so etwas bei grossen PHP-Applikationen zu eklatanten Sicherheitslücken geführt hat, beispielsweise bei phpBB und Wordpress.
Im Januar 2005 wurde das PHP Security Consortium gegründet, welches sich, so die Initiatoren, um Aufklärung im Sicherheitsbereich kümmern soll. Zu diesem Zweck werden auch immer wieder Artikel oder Papers publiziert, die Best Practices behandeln. Sie scheinen aber nicht sehr glücklich damit zu sein?
Während die grundsätzliche Idee eines PHP Security Consortium begrüssenswert ist, lässt die Führung des Konsortiums viel zu wünschen übrig. Auf der Webseite des Zusammenschlusses sind genau zwei kurze Artikel und ein Security Guide zu finden. Weitere eigene Publikationen – mit der Ausnahme einer Zusammenfassung von Bugtraq – existieren nicht. Diese Ausbeute erscheint mir nach 8 Monaten Aktivität und der Zahl der Mitglieder etwas mager. Davon abgesehen, dass in diesen Publikationen von mir wiederholt Beispiele gefunden wurden, die genau das Gegenteil von dem lehren, was beabsichtigt ist. Zusätzlich sind einige der im Security Guide beschriebenen Best Practices in den Augen diverser Sicherheitsspezialisten umstritten. Die meisten Konsortiumsmitglieder erscheinen zudem nach aussen inaktiv. Daher ist es fragwürdig, ob es sinnvoll ist, dass sie ihre Mitgliedschaft zu Marketingzwecken ausbeuten.
Die sehr beliebte Forensoftware phpBB kämpft schon seit längerer Zeit mit Sicherheitslücken, die oftmals identisch sind oder gar, nachdem sie behoben worden, wieder aufbrechen. Fehlen den Entwicklern die nötigen Fähigkeiten oder mangelt es an Sicherheitsbewusstsein?
Ich denke, es ist relativ unfair, phpBB immer den Schwarzen Peter zuzuschieben, wenn es um Sicherheitslücken geht. Es stimmt schon, dass phpBB in jüngster Vergangenheit einige eklatante Lücken aufwies, wie Santy eindrucksvoll demonstriert hat. Aber man darf dabei nicht vergessen, dass phpBB nun mal das am weitesten verbreitete Forum ist und deshalb ziemlich im Rampenlicht steht und die Situation von den Medien allein durch die Präsenz des Wurms etwas aufgebauscht wird. Schaut man nämlich auf die anderen grossen, teils kommerziellen Boards wie vBulletin, Invision Power Board oder Woltlab BB, dann litten sie mindestens in der Vergangenheit unter genauso vielen Lücken, nur hatten sie das Glück, dass ihre Installationsbreite nicht so gross ist und es keinen Wurm gab.
Was die Fähigkeiten der phpBB-Entwickler angeht, kann ich keine Aussage treffen. Man sollte allerdings auch beachten, dass zum Beispiel die Lücke, die Santy ausgenutzt hat, durch eine 1:1-Kopie eines unsicheren Beispiels aus einer externen Quelle entstanden ist.
Sie kritisieren oft auch das mangelnde Verantwortungsbewusstsein von Projektverantwortlichen im Umgang mit Sicherheitslücken, beispielsweise vom Weblog-Tool Wordpress. Was machen die Wordpress-Entwickler falsch?
Grundsätzlich muss ein Entwicklerteam selber wissen und vor sich selbst verantworten, wie es mit Sicherheitslücken umgeht. Solange die Lücken nicht öffentlich bekannt sind, macht es sicherlich auch nicht viel aus, wenn das Beheben etwas länger dauert.
Die Wordpress-Entwickler haben aber bislang einige Kardinalfehler begangen, die man bei der letzten Wordpress-Lücke von Mitte August erkennen kann [CAN-2005-2612]. Zunächst einmal wurde das Problem in ihrem öffentlich zugänglichen Codebaum behoben, ohne dass eine sofortige Veröffentlichung des Problems geplant war. Daraufhin kursierte ein Exploit auf diversen Mailinglisten und Security-Seiten, welcher das Ausführen von beliebigem PHP-Code in Wordpress-Blogs erlaubte. Die Wordpress-Entwickler hätten zu diesem Zeitpunkt ihre User vor diesem Exploit warnen sollen, da sie ja für ein neues Release noch nicht bereit waren. Statt dessen haben sie die Gefahr heruntergespielt, weil der Exploit nur funktioniert, wenn register_globals aktiviert ist. Dabei wurde natürlich verschwiegen, dass dies auf weit mehr als 50 Prozent aller PHP-Installationen der Fall ist. Gekrönt wurde dies alles dann durch ein stilles Aktualisieren des Tarballs nach dem Release der neuen Version. Es sollte eigentlich klar sein, dass es unverantwortlich ist, keinerlei Meldung darüber zu machen, dass die neue Version, welche mehrere Stunden zum Download angeboten wurde, noch nicht abgesichert war.
Was für ein Vorgehen empfehlen Sie, wenn ein Projekt mit einer Sicherheitslücke konfrontiert wird?
Das betroffene Projekt sollte zunächst einmal die nötigen Änderungen zum Beheben der Lücke(n) spät möglichst in öffentliche Code-Bäume einchecken, da es diverse Skripte gibt, die unter anderem nach «Fixes» für Sicherheitslücken in CVS-Commit-Nachrichten suchen. Es ist generell ratsam, diese Änderungen getrennt von neuen Features in separaten Security Releases zu veröffentlichen. In keinem Fall sollten sicherheitskritische Änderungen veröffentlicht werden, ohne dass sie deutlich durch Zusätze oder Änderung der Versionsnummer kenntlich gemacht werden. Schliesslich sollten die User deutlich über die Art der Lücken und ihre Gefahr aufgeklärt werden, da unvollständige Informationen meist zur Unterschätzung der Lücken führen, und ausserdem muss immer beachtet werden, dass User in der Regel nicht selbstständig anhand der Änderungen auf die Lücken schliessen können, wogegen die Angreifer aber gerade darin geschult sind.
Stefan Esser, 26, ist unabhängiger Security Consultant. Er arbeitet bereits seit 5 Jahren am PHP-Projekt mit und ist auch eines der Gründungsmitglieder von PHPs Security Response Team. Weiter entwickelt er mit Hardened PHP (siehe InfoWeek 07/2005) einen Patch für PHP, der sowohl PHP als auch den Server vor schlecht programmierten Scripts und Angriffen schützt, und bietet unter www.hardened-php.net sowohl Auditing als auch demnächst Programmier-Trainings an.
Auch ausserhalb der PHP-Community ist Stefan Esser durch unzählige Security-Advisories bekannt, die unter anderem Lücken in populären Produkten wie Linux, NetBSD, Samba, CVS oder Subversion betreffen. Zudem ist es ihm als erstem gelungen, die DRM-Implementierung von Microsofts XBox über Fehler in der Software zu knacken.
Im zweiten Teil des Interviews mit Stefan Esser dreht sich alles um Server-Sicherheit und was man selber gegen selbst- und fremdverschuldete Sicherheitslücken tun kann.
