Dieser Eintrag soll Einblick in den Alltag des Security-Teams geben. Die Arbeit ist spannend und es steckt weit aus mehr dahinter, als manche/r meinen mag.

Die veröffentlichten Security Bulletins geben nur einen kleinen Ausschnitt der Arbeit preis, denn bis es soweit ist, ist jede Menge Arbeit nötig, die ich gerne näher beschreiben möchte.

1) Eine Sicherheitslücke wird entdeckt

Zu Beginn wird eine Lücke in einer Extension entdeckt. Dies geschieht entweder durch ein Mitglied des Security Teams oder durch einen TYPO3-Anwender, der sich den Code von Extensions näher angeschaut hat und Fehler an das Security Team weitermeldet. In letzterem Fall wird vom Security Team ein Mail an den Informanten verschickt, in dem auf die Extension Security Policy hingewiesen und diese erklärt wird. In kurz:

• Es wird gebeten die Lücke nicht weiter zu melden, weder an Freunde & Bekannte, noch im Bugtracker oder im eigenen Blog und auch nicht an den Autor der Extension.
• Wenn ein Security Bulletin veröffentlicht wird, wird der Name des Melders erwähnt. Falls nicht erwünscht, muss dies extra gemeldet werden.

2) Analyse

Die Qualität der Meldungen unterscheidet sich enorm. Notwendige Informationen sind bzw. sollte sein: Extension-Key, Versionsnummer, Art der Lücke und wo diese auftritt. Hilfreiche ist weiters die Angabe von Zeilennummern, ein HowTo oder Proof of Concept und jede andere Information, die eben für das Security-Team das Leben erleichtert.

Jeder Meldung muss nachgegangen werden und das Problem wird vom Security Team analysiert. Bei einfachen Extensions ist es ausreichend, nur den Code zu lesen, ansonsten muss die Extension installiert und das ganze nachgestellt werden. In vielen Fällen sind unsichere Extensions auch schlecht programmierte und dokumentierte Arbeiten, was die Aufgabe nicht leichter macht.

Am Ende der Analysephase steht fest, dass die Extension entweder unsicher oder alles in Ordnung ist. Bei Unklarheiten spricht man sich nochmalig im Team ab und klärt die Sache gemeinsam.

3) Kommunikation mit dem Entwickler

Das Ergebnis der Analyse wird dem Entwickler der Extension mitgeteilt. Die E-Mail-Adresse findet man zumeist im Code der Extension, ansonsten muss muss man hoffen, dass der Autor in eine der Suchmaschinen vertreten ist.

Im Idealfall ist die Adresse gültig und der Entwickler reagiert  schnell mit eienr ersten Antwort. Für das Beheben von Fehlern gelten folgende Regeln:

• Auch der Entwickler wird auf die Policy hingewiesen und dass er verpflichtet ist, die Extension zu reparieren.
• Der Entwickler hat 21 Tage Zeit, das Problem zu lösen.
• Um die Lösung leichter beurteilen zu können, muss dem Security Team eine Diff-Datei und die neue Extension als t3x zur Verfügung gestellt werden.

Ist der Entwickler nicht erreichbar, meldet sich nicht, beachtet die Fristen nicht oder sagt, dass die Extension von ihm nicht mehr gepflegt wird und gelöscht werden soll, wird die Extension im Repository als unsicher markiert und kann nicht mehr heruntergeladen werden.

4) Bugfix wird bereitgestellt

Wird ein Fix durch den Autor bereitgestellt, wird dieser vom Security Team analysiert und gecheckt, ob die Lücken geschlossen wurden. Wenn nein, geht der Ball zurück zum Autor, ansonsten muss hier folgendermaßen unterschieden werden:

• Collective Security Bulletin (CSB): Damit werden die Extensions abgedeckt, die seltener eingesetzt werden. Eine sichere Version wird durch den Autor sofort im TER bereitgestellt.
• Individual Security Bulletin (ISB): Als ISB werden die Extension gehandelt, die eine weite Verbreitung haben. Diese werden gemeinsam mit der Veröffentlichung des Security Bulletins im Repository aktualisiert.

In beiden Fällen muss durch das Security-Team sichergestellt werden, dass keine älteren und damit unsicheren Versionen der Extension im Repository verfügbar sind. Dazu gibt es eigene Mechanismen auf typo3.org, die dafür angestoßen werden müssen.

5) Vorbereitung des Security Bulletins

Die Öffentlichkeit wird durch die Security Bulletins in Kenntnis gesetzt, dass gewisse Extensions als unsicher gelten. Wurde ein Bugfix bereitgestellt, wird empfohlen, auf diese Version zu aktualisieren. War der Extension Autor nicht erreichbar oder nicht gewillt zu helfen, wird empfohlen die Extension zu löschen.

6) Fazit

Um TYPO3 bzw. die Extensions sicherer zu machen, ist jede Menge Zeit und Arbeit notwendig. Diese wird in aller Regel in der Freizeit abgeleistet und wird nicht bezahlt.

Ich hoffe, ich konnte einen kleinen Einblick geben.