Sicherheitsforscher von Tenable haben eine GerriScary genannte Schwachstelle im Open-Source-Code-Review-System Gerrit von Google entdeckt. Die Schwachstelle ermöglichte das Einschleusen von Schadcode in mindestens 18 zentrale Google Projekte, darunter ChromiumOS (CVE-2025-1568), Chromium, Dart und Bazel. Über GerriScary hätten Angreifer bestehende Change Requests manipulieren, Freigabemechanismen aushebeln und Schadcode in kritische Projekte einschleusen können.
Die Forscher von Tenable fanden heraus, dass falsch konfigurierte Berechtigungen in Gerrit – insbesondere die Einstellung addPatchSet – in Kombination mit der Art und Weise, wie Freigabebedingungen für Change Requests zwischen Revisionen vererbt wurden, einen ausnutzbaren Angriffspfad eröffneten. Dadurch konnten Bedrohungsakteure automatisierte Merge-Prozesse missbrauchen, um ungeprüften Schadcode ohne jegliche Benutzerinteraktion einzuschleusen – und so de facto einen Zero-Click-Supply-Chain-Exploit schaffen.
GerriScary veranschaulicht die vielschichtigen Risiken in Open-Source-Ökosystemen und Entwickler-Workflows, in denen Fehlkonfigurationen und Automatisierung unbeabsichtigt die Angriffsfläche vergrößern können, schrieb mir Tenable.
„Vertrauen ist in der Softwareentwicklung von entscheidender Bedeutung – insbesondere, wenn es um Open-Source-Kollaborationsplattformen wie Gerrit geht”, so Liv Matan, Senior Security Researcher bei Tenable. „GerriScary hat einen ausnutzbaren Angriffspfad eröffnet, über den Bedrohungsakteure etablierte Sicherheitsprotokolle umgehen und zentrale Softwareprojekte direkt kompromittieren konnten – und einmal mehr verdeutlicht, dass selbst die robustesten Ökosysteme jedes einzelne Glied ihrer Lieferkette sorgfältig überprüfen müssen.“
Potenzielle Auswirkungen von GerriScary
Wäre es Angreifern gelungen, GerriScary auszunutzen, hätten sie:
- Schadcode in mindestens 18 weitverbreitete Google Projekte wie Chromium, Bazel und Dart einschleusen können
- menschliche Reviews durch Label-Vererbung und Automatisierung umgehen können
- Code in Software, auf die weltweit Millionen von Nutzerinnen und Nutzern zurückgreifen, manipulieren können
Empfehlungen für Security-Teams
Obwohl Google die Schwachstelle inzwischen behoben hat, empfiehlt Tenable Unternehmen, die Gerrit einsetzen:
- Berechtigungen zu überprüfen – insbesondere die Standardeinstellung addPatchSet
- das Kopieren von Labels zwischen Patch-Sets zu deaktivieren oder einzuschränken
- automatisierte Workflows zu überprüfen, um Race Conditions bei Freigaben zu vermeiden
„GerriScary zeigt deutlich, warum proaktive Sicherheit unverzichtbar ist. In zunehmend komplexen IT-Umgebungen müssen Security-Teams Schwachstellen frühzeitig erkennen und beheben, damit Angreifer erst gar nicht die Chance haben, sie auszunutzen“, ergänzt Matan. Tenable hat die vollständigen Forschungsergebnisse hier veröffentlicht.
Uff, klingt nach Jackpot.
> „Wäre es Angreifern gelungen, GerriScary auszunutzen…“
Hallo Herr Born,
wie kommen Sie zu diesem Konjunktiv, habe ich etwas überlesen? Weder in Ihrem Artikel, noch im Originaltext von Tenable konnte ich einen Hinweis finden, der auf eine Überprüfung der (bereits gepatchten) betroffenen Repositories auf eine „Code-Injektion“ schließen ließe. Auch einen konkreter Hinweis, wie eine solche Manipulation nachträglich zu erkennen sein könnte, hätte ich erwartet – sofern dies denn überhaupt automatisiert möglich ist, hahaha.
Die Details dieser Geschichte klingen eigentlich viel zu schön, um nicht von einer absichtlich platzierte Schwachstelle (aka Hintertür) auszugehen. Doch klar, ich weiß schon: Erkläre nichts mit „Bösartigkeit“, das sich auch mit „Dummheit“ begründen ließe. Dabei stellt sich mir die Frage, ob z.B. Geldgier, wie auch das Geltendmachen beliebiger „höherer Werte“ nicht ganz konkret lezterer Eigenschaft zuzurechnen sind.
Freundliche Grüße!