Original-URL des Artikels: https://www.golem.de/news/travis-ci-falsch-gesetzte-variable-fuehrt-zu-geloeschter-datenbank-1804-133731.html    Veröffentlicht: 09.04.2018 12:45    Kurz-URL: https://glm.io/133731

Travis CI

Falsch gesetzte Variable führt zu gelöschter Datenbank

Der mit Github genutzte Dienst Travis-CI war für mehrere Stunden nicht erreichbar. Der Grund ist offenbar eine falsch gesetzte Variable eines Entwicklers, die zum Verlust der Produktivdatenbank geführt hat. Eventuell waren Nutzerdaten für andere einsehbar.

Bereits Mitte März ist der in Verbindung mit dem Code-Hoster Github verwendete Dienst Travis CI für fast acht Stunden nicht erreichbar oder nicht nutzbar gewesen. In einer ausführlichen Analyse beschreibt das Betreiberteam des Continuous-Integration-Dienstes, wie es dazu kommen konnte: Offenbar hat einer der Entwickler versehentlich die Produktivdatenbank gelöscht, indem alle Tabellen als leer markiert worden sind (Truncate). Eigentlich sollte dies nur auf einem Testsystem geschehen, eine falsch gesetzte Variable führte den Test jedoch auf dem Produktivsystem durch.

Das Terminal, in dem der Befehl ausgeführt worden ist, war eine mehrere Tage alte Tmux-Sitzung, in der die Umgebungsvaribale DATABASE_URL für das Produktivsystem noch gesetzt war. Der betroffene Entwickler hat demnach zuvor über die Sitzung und die Variable das Produktivsystem untersucht, kehrte für das Ausführen der Tests aber "unwissentlich" in diese Sitzung zurück, ohne den Inhalt der Variable zu ändern. Dass das Team überhaupt auf diese Weise Schreibzugriff auf das Produktivsystem hat, führen die Betreiber auf schlechte Werkzeuge zurück, die die Arbeit mit der Read-only-Kopie erschwerten. Der direkte Zugriff sei eine "übliche Abkürzung". Die Datenbank ist nach dem Fehler aus einem Backup wieder hergestellt worden.

Um solche Fehler künftig komplett zu vermeiden, hat das Travis-Team eigenen Angaben zufolge die Rechteoptionen für den Truncate-Befehl entfernt. Darüber hinaus überprüft ein internes Werkzeug künftig, ob die Variable gesetzt ist und warnt die Entwickler in diesem Fall. Für das genutzte Testwerkzeug Database Cleaner hat das Team ebenfalls eine Schutzfunktion gebaut, damit über die Variable nicht aus Versehen auf eine entfernte Datenbank zugegriffen wird.

Eventuell Nutzerdaten betroffen

Da nach dem Löschen der Datenbank die Anwendungen des Dienstes selbst noch rund 30 Minuten online gewesen sind, habe es beim Login zu Überscheidungen der Nutzer kommen können, so dass Daten eventuell von Dritten einsehbar waren. Der Untersuchung zufolge habe mindestens ein Nutzer in diesem Zeitraum zumindest theoretisch Zugriff auf Daten gehabt. Davon möglicherweise betroffene Kunden und Nutzer hat das Team von Travis bereits informiert.

Dass bestimmte Dienste wegen Problemen mit gelöschten Datenbanken ausfallen, kommt immer wieder vor. So hatte im vergangenen Jahr ein Mitarbeiter von Github-Konkurrent Gitlab versehentlich die Produktivdatenbank gelöscht, auch der Cloud-Hoster Digital Ocean hatte im vergangenen Jahr mit solch einer Panne zu kämpfen.  (sg)


Verwandte Artikel:
Akamai: Github übersteht bislang stärksten DDoS-Angriff   
(02.03.2018, https://glm.io/133105 )
Owncloud/Nextcloud: Passwörter im Bugtracker   
(19.04.2017, https://glm.io/127346 )
OWASP Top 10: Die zehn wichtigsten Sicherheitsrisiken bekommen ein Update   
(24.04.2017, https://glm.io/127426 )
TV-Kabelnetz: Vodafone Kabelnetztrasse in Rheinland-Pfalz zerstört   
(23.01.2018, https://glm.io/132323 )
Verschlüsselung: Github testet Abschaltung alter Krypto   
(09.02.2018, https://glm.io/132684 )

© 1997–2018 Golem.de, https://www.golem.de/