GitLab ist die Software, mit der viele Agenturen und Entwicklungsabteilungen ihren Programmcode verwalten. Wer eine Website, einen Shop oder eine Branchenlösung entwickeln lässt, hat seinen Code mit einiger Wahrscheinlichkeit auf einem GitLab-Server liegen, oft auf einem eigenen beim Dienstleister. Darauf liegt mehr als Code: Zugangsdaten für Server, Schlüssel für Schnittstellen, nicht selten die Passwörter der Produktion.
Vier Lücken in einem Monat
Am 12. Oktober hat GitLab eine Lücke mit der Höchstbewertung 10 von 10 geschlossen. Über ein präpariertes Suchmuster, einen sogenannten regulären Ausdruck, in der Konfiguration für automatische Abläufe konnte jemand ohne Anmeldung Code auf dem Server ausführen. Seit dem 29. Oktober führt die US-Behörde für Cybersicherheit CISA diese Lücke in ihrer Liste der nachweislich ausgenutzten Lücken.
Am 21. Oktober folgte die nächste, wieder mit 10 von 10. Betroffen sind alle Versionen seit 2014, auch die Versionen vom 12. Oktober. Wer damals sofort aktualisiert hat, musste neun Tage später noch einmal. Zählt man zwei weitere Lücken derselben Art aus einer Version davor dazu, sind es vier innerhalb weniger Wochen.
Der Fehler steckt nicht in GitLab
Alle vier gehen auf Fehler in Ruby zurück, der Programmiersprache, in der GitLab geschrieben ist, genauer in ihrem Baustein für Suchmuster. GitLab hat die Fehler gefunden, sein mitgeliefertes Ruby selbst korrigiert und die Lücken unter eigenem Namen gemeldet. Das Ruby-Projekt hat die Korrekturen erst am 23. Oktober veröffentlicht, in den Versionen 4.0.9, 3.4.12 und 3.3.13.
Daraus folgen zwei Dinge, die in keiner Warnung zu GitLab stehen.
Wer GitLab aus den offiziellen Paketen installiert, bekommt das korrigierte Ruby mit dem GitLab-Update. Das gilt für das Linux-Paket und die offiziellen Container.
Wer GitLab anders betreibt, etwa mit dem Ruby des Betriebssystems, muss Ruby selbst aktualisieren. Das GitLab-Update allein schliesst die Lücke dann nicht.
Dazu kommt: Ruby hat für die Fehler bisher keine eigenen Kennnummern beantragt. Prüfprogramme, die installierte Software automatisch mit den Verzeichnissen bekannter Lücken abgleichen, kennen nur die GitLab-Nummern. Sie warnen bei einem alten GitLab, aber nicht bei einem alten Ruby. Und betroffen ist laut Ruby jede Anwendung, die Suchmuster aus fremden Eingaben erzeugt, nicht nur GitLab. Es ist dasselbe Muster wie letzte Woche bei Brotli: ein Baustein in vielen Programmen.
Was das für uns heisst
Wir betreiben selbst einen GitLab-Server, aus dem offiziellen Paket. Er ist von den automatischen Updates ausgenommen, weil ein GitLab-Update den Dienst für einige Minuten unterbricht und wir den Zeitpunkt selbst wählen wollen. Am 22. Oktober haben wir ihn auf 19.5.1 gebracht, die Version mit der Korrektur vom Vortag.
Die Kehrseite dieser Entscheidung ist uns bewusst: Jedes Update braucht jemanden, der es auslöst. Am 29. Oktober ist mit 19.5.3 schon das nächste erschienen. Ein Paket, das man von Hand aktualisiert, ist nur so aktuell wie der letzte Blick in die Ankündigungen.
Was jetzt zu tun ist
Beim Dienstleister nachfragen. Wer Code bei einer Agentur oder einem Entwickler liegen hat, fragt: Läuft bei euch ein eigenes GitLab, und in welcher Version? Geschützt sind 19.5.1, 19.4.3, 19.3.6, 19.2.9 und neuer, für ältere Zweige nennt GitLab eigene Versionen. Eine gute Antwort kommt mit der Versionsnummer.
Wer selbst betreibt: auf die aktuelle Version des eigenen Zweigs gehen, nicht auf die vom 12. Oktober. Läuft GitLab nicht aus dem offiziellen Paket, zusätzlich Ruby auf 3.3.13, 3.4.12 oder 4.0.9 bringen.
Nicht alles ins Internet stellen. Ein GitLab, das nur das eigene Team braucht, kann hinter einem VPN stehen. Was von aussen nicht erreichbar ist, wird auch nicht im Vorbeigehen angegriffen.
Nach Spuren sehen. GitLab nennt zwei Anzeichen für Angriffsversuche: Abstürze des Bausteins für Suchmuster, der Onigmo heisst, und gehäufte Fehler beim Darstellen von Org-Dateien in den Protokollen. Wer solche Einträge seit Mitte Oktober findet, sollte von einem Einbruch ausgehen. Dann reicht das Update nicht mehr: Alle Zugangsdaten und Schlüssel, die auf dem Server lagen, gehören geändert.
Andere Ruby-Anwendungen nicht vergessen. Läuft im Betrieb weitere Software auf Ruby, etwa ein Ticketsystem oder eine Projektverwaltung, gilt dieselbe Frage: Welche Ruby-Version steckt darin?