Studie: GitHub markiert umgeschriebene signierte Commits weiter als „Verifiziert“

Zusammenfassung

Eine neue Analyse von Jacob Ginesin, Doktorand an der Carnegie Mellon University und kryptografischer Auditor bei Cure53, stellt eine verbreitete Annahme über signierte Git-Commits infrage: Ihr Hash ist offenbar nicht zwangsläufig ein eindeutiger, unveränderlicher Bezeichner. Nach Ginesins Forschung kann aus jedem signierten Commit ein zweiter Commit mit identischen Dateien, demselben Autor und Datum sowie weiterhin gültiger Signatur erzeugt werden – auch ohne den Signaturschlüssel zu besitzen. GitHub kennzeichnet solche Varianten demnach weiterhin als „Verifiziert“. Relevant ist das, weil viele Werkzeuge und Prozesse einen verifizierten Commit-Hash als dauerhaften, eindeutigen Verweis auf seinen Inhalt behandeln. Laut der Arbeit können damit etwa Blocklisten umgangen werden: Wird ein schädlicher Commit nur über seinen Hash gesperrt, lässt sich derselbe Inhalt unter einem neuen, weiterhin als verifiziert markierten Hash erneut veröffentlichen. Betroffen sind nach der Beschreibung auch Systeme zur Deduplizierung, Herkunftsdokumentation und reproduzierbaren Builds, sofern sie den Commit-Hash als Schlüssel verwenden. Eine CVE oder Herstellerwarnung gibt es nicht; die Arbeit verortet das Problem bei der Definition dessen, was eine Forge als „Verifiziert“ akzeptiert.

Ginesins fünfseitige Arbeit, die auf arXiv veröffentlicht wurde, wird von einem öffentlich verfügbaren Werkzeug begleitet, das laut Beschreibung alle drei Angriffspfade demonstriert. Hinzu kommen zwei Demo-Repositories, in denen die manipulierten Commits auf GitHub weiterhin als „Verifiziert“ angezeigt werden. Der zentrale Punkt: Prüfer sehen identische Dateien, denselben Autor, dasselbe Datum und eine gültige Signatur – nur der Commit-Hash ist ein anderer.

Die Ursache bezeichnet Ginesin als Formbarkeit von Signaturen. Der Hash eines Commits wird über den gesamten Inhalt berechnet, einschließlich der Rohbytes der Signatur im Header. Viele Signaturen lassen sich jedoch in eine andere, weiterhin gültige Form umschreiben. Werden diese Bytes verändert, ändert sich der Hash, ohne dass auch nur eine Zeile Code angepasst werden muss.

Die drei beschriebenen Wege decken laut der Arbeit alle GPG-Verfahren ab, die GitHub verifiziert, außerdem S/MIME. Gemeinsam ist ihnen, dass GitHub eine Signatur vor der Prüfung nicht normalisiert. Die Studie nennt dabei drei Punkte ausdrücklich: keine strikte Kodierung bei S/MIME, kein Entfernen bestimmter OpenPGP-Felder und die Akzeptanz nicht-kanonischer ECDSA-Werte in ihrer vorliegenden Form.

GitHub hinterlegt demnach einen „Verifiziert“-Eintrag für jeden einzelnen Commit-Hash und prüft ihn später nicht erneut. Deshalb bleibt ein Commit nach Ginesins Darstellung sogar dann als „Verifiziert“ markiert, wenn der zugehörige Signaturschlüssel inzwischen widerrufen wurde. Werden Original und manipuliertes Gegenstück in zwei verschiedene Branches übertragen, behandelt GitHubs Vergleichsansicht sie als auseinanderlaufende Historien – mit jeweils einem Commit Vorsprung und Rückstand –, obwohl die Dateien identisch sind.

Wichtig ist laut der Arbeit auch, was hier gerade nicht passiert: Es handelt sich nicht um eine Hash-Kollision. Weder SHA-1 noch SHA-256 werden gebrochen, und die Beobachtung hat nichts mit Gits Übergang zu SHA-256 zu tun. Es werden also nicht zwei verschiedene Commits auf denselben Hash gezwungen; vielmehr kann ein und derselbe Commit auf mehrere gültige Arten dargestellt werden, jeweils mit eigenem Hash.

Weil jeder Commit seinen Vorgänger per Hash referenziert, zieht die Manipulation eines Commits neue Hashes für alle nachfolgenden Commits nach sich. Das bereitgestellte Werkzeug schreibt diese Kette konsistent um. Ein signierter Nachfolge-Commit verliert laut Ginesin allerdings sein eigenes Abzeichen, sobald sich der Verweis auf den Eltern-Commit ändert. Diesen Effekt nennt er „Formbarkeit der Hash-Kette“.

Die Arbeit zieht außerdem eine Parallele zu einem alten Problem bei Bitcoin: Dort konnte bei ECDSA-Signaturen der s-Wert gespiegelt und so die Transaktions-ID verändert werden, ohne den Schlüssel des Besitzers zu kennen. Bitcoin reagierte darauf, indem nur noch die „Low-S“-Form akzeptiert wurde; später wurden Signaturen mit SegWit ganz aus der ID herausgelöst. Ginesins Schlussfolgerung ähnelt dieser Lehre: Bevor ein Hash als vertrauenswürdig gilt, muss die Signatur kanonisiert werden.

Bezug nimmt die Studie auch auf die jüngsten Tag-Übernahmen bei GitHub Actions, konkret auf die Angriffe auf tj-actions/changed-files im Jahr 2025 und trivy-action im Jahr 2026; Letzteren zitiert sie ausdrücklich. Die bisherige Empfehlung, auf vollständige Commit-Hashes statt auf verschiebbare Tags zu pinnen, bleibt laut Text richtig. Ein gepinnter Hash liefert weiterhin genau den erwarteten Code oder schlägt fehl. Die neue Arbeit schränkt diese Praxis nicht ein, warnt aber davor, aus einer gültigen Signatur abzuleiten, der Commit-Hash sei damit zugleich ein einzigartiger Name für seinen Inhalt.

Handlungsbedarf sieht Ginesin vor allem bei den Forges und bei Werkzeugen, die Commits anhand ihres Hashes blockieren, deduplizieren oder Herkunftsdaten protokollieren. Sie sollten Signaturen zuerst verifizieren und kanonisieren, statt dem Roh-Hash eines signierten Objekts zu vertrauen, das ein Angreifer neu kodieren kann. Ginesin sagt, er habe das Problem im Januar an GNU und Git sowie im März an GitHub gemeldet. Zum Zeitpunkt der Veröffentlichung der Arbeit habe weder Git noch eine Forge das Problem behoben. Als naheliegenden ersten Schritt nennt die Studie den S/MIME-Fall, weil GitHub dort weiterhin etwas akzeptiere, das eine strikte lokale Prüfung zurückweist.

Studie: GitHub markiert umgeschriebene signierte Commits weiter als „Verifiziert“

Ähnliche Artikel

Neueste Artikel