Menü
Security

GitHub-Sicherheitslücke kompromittiert alle Projekte

vorlesen Drucken Kommentare lesen 131 Beiträge

Über eine Schwachstelle im Web-Framework Ruby On Rails lassen sich nicht nur Beiträge schreiben und löschen. Der Russe Egor Homakov fand sogar einen Weg, den Quellcode beliebiger GitHub-Projekte zu manipulieren.

Zuvor hatte Homakov den Fehler im Issue Tracker von Rails gemeldet. Zuerst wiegelten die Entwickler dort ab: Die Sicherung einer Anwendung sei Aufgabe des jeweiligen Entwicklers. Das Ticket wurde mehrfach geschlossen und wieder geöffnet. Daraufhin demonstrierte Homakov das Problem anhand einer prominenten Ruby-on-Rails-Anwendung: GitHub selbst.

Um die Aufmerksamkeit der Rails-Entwickler zu wecken, erzeugte er zuerst ein Issue mit einem 1001 Jahre in der Zukunft liegenden Datum. Dann trug er seinen Public Key in die Liste der Rails-Committers ein und fügte Code zum Rails Master Repository hinzu. Damit hatte er die gewünschte Aufmerksamkeit: GitHub löschte den Key, suspendierte Homakovs Konto und begann mit einer Analyse des Problems. Nach Beseitigung der Lücke veröffentlichte Homakov eine Anleitung, auf welchem Weg er GitHubs Rails-Anwendungen manipuliert hatte.

Die Homakovs Hack zugrundeliegende "Mass-Assignment Vulnerability" ist schon länger bekannt. Es entstand, als Rails die Möglichkeit einführte, mit einem Aufruf gleichzeitig mehrere Attribute zu setzen. Die Rails Security Guide erklärt das Problem. Zudem wird dort beschrieben, wie man Attribute über Blacklists und Whitelists sperrt beziehungsweise freigibt. Da die Whitelisting-Funktion standardmäßig nicht aktiv ist, besteht die Lücke für viele Rails-Anwendungen weiterhin.

GitHub ist weiterhin mit der Code-Überprüfung beschäftigt. In einem Blog-Eintrag hielt die Firma fest, Homakov habe zwar zwei Tage zuvor ein Problem gemeldet, habe aber zusätzlich ohne Vorwarnung eine "Public Key Form Update Vulnerability" ausgenutzt. Das GitHub-Nutzerkonto von Homakov wurde mittlerweile wiederhergestellt. Auf den Hilfeseiten von GitHub findet sich jetzt eine Anleitung zur verantwortungsbewussten Meldung gefundener Sicherheitslücken.

Wie unsere Kollegen bei H-Online hervorheben, stellt das Mass-Assignment Issue für andere Rails-Anwendungen ein unvermindertes Problem dar. Entwicklern sollten daher ihren Code daraufhin untersuchen, ob ihre Systeme sich nach derselben Methode manipulieren lassen. Ein neuer Commit zum Rails-Code forciert die Whitelist für Attribute als Standardeinstellung – sie gilt allerdings nur für neu angelegte Anwendungen. Vermutlich wird die Änderung in einem Update zu Rails 3.2 veröffentlicht. (ghi)