Sicherheitsspezialist verlässt resigniert PHP-Security-Team

Stefan Esser hat in seinem Blog den sofortigen Austritt aus dem PHP Security Response Team verkündet. Die Gründe seien vielfältig, der wichtigste sei aber, erkannt zu haben, dass seine Versuche, PHP "von innen" sicherer zum machen, ausssichtslos seien.

In Pocket speichern vorlesen Druckansicht 411 Kommentare lesen
Lesezeit: 4 Min.
Von
  • Daniel Bachfeld

Stefan Esser, PHP-Sicherheitsspezialist und Mitglied des offiziellen PHP Security Response Teams hat nach eigenen Angaben die Faxen dicke: In seinem Blog verkündet er den sofortigen Austritt aus dem PHP Security Response Team. Die Gründe seien vielfältig, der wichtigste sei aber, erkannt zu haben, dass seine Versuche, PHP "von innen" sicherer zu machen, ausssichtslos seien. Sobald man die Sicherheit von PHP kritisiere, werde man im Security Team selbst zur "Persona non Grata". Zudem würden viele seiner Vorschläge ignoriert, weil die Entwickler behaupten, Essers Wortwahl sei zu unfreundlich. Er habe aufgehört zu zählen, wie oft er als Verräter beleidigt wurde, wenn er einen Fehlerbericht zu einer Lücke in PHP veröffentlicht habe.

Zukünftig wolle Esser seine Berichte aber weiterhin veröffentlichen, allerdings ohne Rücksicht darauf zu nehmen, ob ein Patch verfügbar ist oder nicht. Auch wolle er die bis dato langsamen Reaktionszeiten von der Entdeckung einer Lücke bis zu Veröffentlichung der Informationen nicht weiter verschleiern. Ohnehin sei nun mit wesentlich mehr Veröffentlichungen über Schwachstellen in PHP durch ihn zu rechnen.

Der Streit zwischen Esser und dem PHP-Team scheint sich insbesondere an der Auffassung zu entbranden, wie die Sicherheit von PHP verbessert werden könne. Während Esser der Meinung ist, dass einige Funktionen von PHP an sich unsicher (etwa allow_url_fopen/allow_url_include) sind und daher überarbeitet werden sollten, sind viele Entwickler, unter anderem des PHP-Spezialisten Zend, der Meinung, dass die Unsicherheit von PHP-Applikationen nur durch unerfahrene Programmierer verursacht werde. Gegenüber heise Security erklärt Zeev Suraski, CTO von Zend, dass der größte Teil von Webanwendungen in PHP programmiert werde. Aufgrund der Masse könne es den Anschein haben, als sei PHP an sich unsicher.

Suraski bedauert den Austritt von Esser aus dem Security Team und hofft, dass sich Esser noch einmal besinnt und die Entscheidung rückgängig macht. Zudem hoffe er, dass sich Esser nicht gegen das PHP-Projekt wende. Der von Esser eventuell angedachte "Month of PHP Security Bugs" für 2007 würde dem Projekt schaden. Er habe aber in der Vergangenheit viel dazu beigetragen, die Implementierung von PHP zu verbessern und sicherer zu machen – auch wenn es Differenzen über die Art und Weise gegeben habe. Falsch sei aber, dass das PHP-Projekt versuche, zu vertuschen, dass PHP höchst unsicher implementiert sei. Man bevorzuge aber einen Patch erstellen zu können, bevor ein Fehlerbericht veröffentlicht wird.

Esser geht das aber zu langsam. Vom Bugreport bis zur Behebung vergehe in seinen Augen zuviel Zeit. Zudem fühlten sich seiner Meinung nach auf der PHP-Sicherheitsmailingliste höchstens 3 Leute genötigt, einen Fehler zu fixen. Teilweise würden Bugs nicht korrekt behoben oder wieder eingeführt. Dies falle oft nicht auf, weil es unter anderem keine Testfälle für Exploits gebe und dies grundsätzlich abgelehnt werde. "Allerhöchstens dürfte der entsprechende Bug in einem Testfall behandelt werden, aus dem nicht direkt ersichtlich ist, dass es ein Exploit testet und nicht direkt zum Angriff genutzt werden kann", erklärte Esser gegenüber heise Security.

Richtig sei hingegen, dass es zu viele unerfahrene Programmierer gebe, allerdings gebe es in PHP auch einfach viel zu viele Randbedingungen die zu beachten seien, damit die Anwendung nicht unsicher wird. Zudem sei es in seinen Augen unverantwortlich, den PHP4-Baum nicht mehr wirklich zu supporten. In der aktuellen CVS Version seien einige Bugfixes für Sicherheitslücken enthalten auf die die Nutzer schon seit Monaten warten. "Darüberhinaus sind auch weitere Lücken behoben, für die entweder noch kein Advisory von dritter Seite veröffentlicht wurde, oder die von einem PHP Entwickler gefunden und behoben wurden und über die es daher, wie immer in diesem Fall, kaum Informationen geben wird.", schreibt Esser in einer E-Mail.

Siehe dazu auch:

(dab)