Login
Newsletter
Werbung

Mo, 5. März 2012, 15:55

Software::Security

Massive Sicherheitslücke in Github geschlossen

Die Projekt-Hosting-Seite Github, Heimat von hunderttausenden Open-Source-Projekten, wies bis gestern eine Sicherheitslücke auf, mit der jeder Benutzer Admin-Rechte für jedes Projekt erhalten konnte.

Es begann offenbar damit, dass der Entwickler Egor Homakov ein Feature in Rails fand, das bei falscher Anwendung zu einer Sicherheitslücke wird. Es handelt sich um die Massenzuweisung von Formularvariablen, bei der schon PHP auf schmerzhafte Art erfahren musste, dass sie keine gute Idee war. Homakov meldete den Fehler bei Rails, doch die Entwickler wollten darin ein Problem der Anwender sehen, die Rails-Anwendungen entwickeln - zumindest vorerst.

Um dem Rails-Projekt auf die Sprünge zu helfen, suchte Homakov nach Code, der verwundbar war - und wurde fündig bei Github, wo auch Rails selbst seine Heimat hat. Nachdem er in zwei Test-Accounts die Sicherheitslücke erprobt hatte, zeigte er dem Rails-Projekt, dass er volle Admin-Rechte erlangt hatte und beispielsweise Fehlerberichte nach Belieben öffnen, schließen und sogar aus der Zukunft schreiben konnte. Außerdem fügte er dem Repositorium eine Datei hinzu. Auch das vollständige Löschen der gesamten Projekthistorie wäre möglich gewesen.

Aufgrund dieses »Einbruchs« sah sich Github genötigt, eine Warnung herauszugeben. Die Sicherheitslücke wurde innerhalb kürzester Zeit behoben und der Account von Homakov suspendiert. Die Offenheit, mit der Github mit dem Problem umging, wurde zwar von vielen Kommentatoren gelobt, andere hingegen hielten sie für unzureichend. Wenig später ließ Github eine weitere Verlautbarung folgen, in der sich das Unternehmen für die Unklarheiten der ersten Mitteilung entschuldigte, seine Richtlinien zur Bekanntgabe von Sicherheitslücken klarstellte und den Account von Homakov wieder herstellte. Einige Beobachter meinen allerdings, dass Github dem Entwickler zumindest noch eine öffentliche Entschuldigung oder sogar Dank schulde.

Die Entwickler von Rails scheinen aus dem Vorfall auch Konsequenzen ziehen zu wollen und die gefährliche Funktion zumindest auf Produktivsystemen standardmäßig abschalten zu wollen. Dabei stehen sie aber dem Problem gegenüber, dass sie durch die Änderung nicht die vielen Anwendungen, die auf die Funktion angewiesen sind, plötzlich funktionsunfähig machen wollen. Für Rails 3 ist offenbar eine Lösung als Plugin geplant.

Werbung
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung