Wer seinen eigenen GitLab-Server betreibt und den Juni-Patch verschlafen hat, sollte jetzt schnell handeln. Die Sicherheitsforscher von depthfirst haben am 24. Juli funktionierenden Exploit-Code veröffentlicht — für eine Lücke, die GitLab bereits sechs Wochen zuvor, am 10. Juni, geschlossen hatte.
SO gefährlich ist die Lücke
Der Exploit führt Befehle als Systemnutzer „git“ aus — und zwar auf jedem Self-Managed-Server der Version 18.11.3, der das Update nicht eingespielt hat. Das Erschreckende: Es braucht keine Admin-Rechte, keinen CI-Zugriff, kein Opfer, das irgendwo klickt. Jeder angemeldete Nutzer, der Code in ein Projekt pushen darf, kann den Angriff fahren.
Ein raffinierter Trick
Die Angriffskette ist clever aufgebaut: Der Angreifer committet ein präpariertes Jupyter-Notebook und öffnet dessen Commit-Ansicht. Das verrät einen Zeiger auf den Arbeitsspeicher. Genug solcher Anfragen, und ein automatischer Suchlauf findet die Programmbibliotheken im Speicher. Zwei weitere Notebooks feuern dann die eigentliche Schadlast ab.
Kurios: Weder die Veröffentlichung von depthfirst noch GitLabs Release-Notes vom 10. Juni nennen für die beiden verketteten Fehler eine offizielle CVE-Nummer oder einen CVSS-Wert. Nach eigenen Angaben war depthfirst zum Zeitpunkt der Veröffentlichung keine Ausnutzung in freier Wildbahn bekannt — was sich mit einem öffentlichen Exploit aber schnell ändern kann.
Das solltest du jetzt tun
Prüfe die Version deiner GitLab-Installation und spiele das Update ein, falls du noch auf 18.11.3 (oder älter, ungepatcht) läufst. Wer GitLab in der Cloud über GitLab.com nutzt, ist von dieser Self-Managed-Lücke nicht betroffen — der Anbieter hält die Version selbst aktuell.