LONDON / LONDON (IT BOLTWISE) – Eine neue Untersuchung zeigt, dass GitHub signierte Commits mit „Verified“ kennzeichnet, obwohl derselbe Commit über eine Signatur-Umkodierung neue Hashes bekommt. Das klingt nach Theorie, hat aber eine praktische Angriffsfläche: Systeme, die Commits über ihren Hash als „einmalig“ blockieren oder deduplizieren, können dieselben Inhalte unter neuen Hashes erneut ausliefern. Die Korrektur liegt nicht bei Entwickler-Repos, sondern bei den Forges: Signaturen müssen vor der Hash-Vertrauensannahme kanonisiert werden. Für Enterprise-Teams bedeutet das, dass man Hash-Logik und Protokollprüfungen stärker absichern sollte.
GitHub markiert signierte Commits traditionell mit dem Status „Verified“. Genau dieser Blick auf den Commit-Hash als dauerhaft eindeutigen Fingerabdruck gerät nun unter Druck: Eine Arbeit von Jacob Ginesin, PhD-Student an der Carnegie Mellon University und Krypto-Auditor bei Cure53, beschreibt „hash chain malleability“ – also die Möglichkeit, dass für denselben Inhalt neue Commit-Hashes entstehen, ohne dass die Signatur ungültig wird und ohne dass die Dateien im Commit verändert werden. Der Knackpunkt: Der Hash eines Commits hängt nicht nur von den Nutzdaten ab, sondern auch von der Rohkodierung der Signaturbytes. Damit können Angreifer signierte Objekte in äquivalente, aber byte-rekonstruierte Formen umschreiben und erhalten erneut „Verified“-Badges.
Die Wirkung ist besonders relevant für Systeme, die auf den Commit-Hash als universelle, stabile Namensgebung setzen. In der Analyse wird ein konkreter Fehlschluss beschrieben: Blockt man „einen schlechten Commit“ über dessen Hash, kann ein Angreifer den gleichen Änderungsinhalt, Autor und Zeitstempel in einen zweiten Commit überführen und dabei eine formal gültige Signatur so neu kodieren, dass GitHub weiterhin „Verified“ ausweist. Reviewer-Checks, die auf Autor, Signaturprüfung und inhaltliche Details zielen, fallen damit nicht sofort ins Auge. Deduplication-Mechanismen, Provenance-Logs und reproduzierbare Build-Aufzeichnungen, die Hashes als alleinigen Schlüssel verwenden, erben dieses „Soft Spot“-Verhalten. Wichtig: Es ist keine Hash-Kollision und kein „Umgehen“ der Signaturprüfung mit anderem Code – identische Inhalte liefern identische Dateien, nur der Hashname unterscheidet sich.
Technisch lässt sich der Angriff auf eine Klassenlücke zurückführen: Signaturen werden vor dem Hash-Trust-Check nicht zuverlässig normalisiert. In Git wird der Commit-Hash typischerweise über den gesamten Commit-Content inklusive Headerbestandteilen berechnet; bei signierten Commits zählen die Bytes der Signatur hinein. Wenn nun die Signaturform variieren kann, ohne die kryptografische Gültigkeit zu brechen, ändert sich der Commit-Byte-Stream und damit der Hash. Das Papier unterscheidet drei Routen, die unterschiedliche Schlüsseltypen betreffen. Bei ECDSA lässt sich das bekannte s-Symmetrieprinzip nutzen (Ersetzen von s durch n−s), sodass beide Formen mathematisch gültig bleiben. Bei RSA und EdDSA wird ein zusätzliches, in einem „unhashed“-Signature-Bereich ignoriertes Feld ergänzt, das GitHub akzeptiert, während der Commit-Byte-Hash dennoch neu entsteht. Beim S/MIME (X.509) wird die Länge in der DER-Struktur verlängert bzw. In eine nicht kanonische, aber weiterhin akzeptierte Form umgeschrieben.
Der organisatorische Teil der Bedrohung entsteht dann aus dem Kettenmechanismus von Commits: Jeder Commit referenziert seine Eltern über Hashes. „Malleation“ eines einzelnen signierten Commits erzwingt dadurch neue Hashes für alle darüberliegenden Commits, weil die Parent-Pointer im Datensatz neu verankert werden müssen. Das im Paper verlinkte Tool erzeugt deshalb nicht nur ein „Twin“-Objekt, sondern rewires die Hash-Kette so, dass die Signaturen für den jeweiligen Schritt wieder gültig sind und GitHub die Badges konsistent beibehält. Gleichzeitig verliert ein signierter Descendant-Commit seinen „Verified“-Status, sobald der Parent-Zeiger geändert wird, was erklärt, warum die Kettenarbeit mit neuer Signaturkodierung zentral ist. Im Ergebnis kann ein kompromittierter oder feindseliger Mirror signierte, „Verified“-Commits bereitstellen, deren Hashes vom kanonischen Forge abweichen.
Der Markt-Kontext ist hier weniger „welche Software ist anfällig“ als „welche Sicherheitsannahme ist zu eng“. Branchenüblich ist, dass Foren, SOC-Workflows und Supply-Chain-Scanner Commits über Hashes pinnen oder blocken. Das Paper knüpft deshalb an bekannte Vorfälle rund um GitHub Actions und Tag-Missbrauch an, bei denen Pinnen auf bewegliche Referenzen ein echtes Risiko darstellte. Die ursprüngliche Best Practice – auf einen vollen Commit-Hash statt auf einen Tag zu pinnen – bleibt davon unberührt und verhindert weiterhin eine Reihe von „Action Swap“-Szenarien. Die neue Erkenntnis verschiebt aber die Aufmerksamkeit: Eine gültige Signatur belegt die Identität des Signierenden, sie macht den Commit-Hash aber nicht automatisch zu einer „one-of-a-kind“-Bezeichnung für den Inhalt über alle Re-Encodings hinweg. Für Systeme, die sich an „Verified“-Hash-Logik klammern, entsteht damit eine zweite Ebene der Absicherung.
Wie stark dieses Problem wirkt, hängt vom Modell der jeweiligen Lösung ab. Wer zusätzlich einen unabhängigen Hash der tatsächlich heruntergeladenen Dateien prüft – etwa über Nix-ähnliche fixed-output Derivationen – hat einen Rückhalt, weil die Inhalts-Äquivalenz früher oder später gegen einen File-Hash oder eine Build-Deterministik abgeglichen wird. Dagegen sind Workflows, die nur „verifiziertes Git-Objekt per Commit-Hash“ als Endkriterium nehmen, eher exponiert: Ein Angreifer kann denselben Inhalt unter anderer Commit-Bytekodierung und neuem Hash bereitstellen, ohne dass GitHub die Signaturprüfung grundsätzlich ablehnt. In der Praxis heißt das: Teams sollten ihre Compliance- und Protokollketten so designen, dass sie kanonische Serialisierung berücksichtigen oder wenigstens eine zweite, inhaltsbasierte Verifikation einziehen. Vergleiche zu anderen Forges wie GitLab oder Bitbucket zeigen, dass die Kernfrage übergreifend ist: Wie genau und an welcher Stelle normalisiert die Plattform die Signatur vor der Vertrauensableitung?
Für die Zukunft liefert das Paper einen klaren Handlungsrahmen, der gut mit bekannten Lehren aus der Kryptografie-Geschichte zusammenpasst: Bitcoin musste einst die ECDSA-s-Symmetrie ebenfalls „zähmen“, indem nur die „low-S“-Form akzeptiert wurde; später wurde mit SegWit auch die Signaturbeteiligung am Transaktions-Identifikator entschärft. Hier ist die Analogie ähnlich, nur auf Git-Kontexte übertragen: Kanonisieren, bevor man den Hash als stabilen Namen interpretiert. Ginesin berichtet, dass er die Problematik bereits im Januar an GNU und Git gemeldet hat und im März an GitHub; bis zur Veröffentlichung der Arbeit seien dort keine Lösungen erfolgt. Der explizite Fix liegt damit bei der Forge-Implementierung: Signaturen sollten auf eine kanonische Darstellung abgebildet werden, bevor die Plattform den „Verified“-Status mit dem Commit-Hash dauerhaft verknüpft oder protokolliert.
Für Entwickler und Security-Teams lautet die praktische Konsequenz daher nicht „Repo ändern“, sondern „Grenzen der Hash-Annahme verstehen“. Wer auf eigene Blocklisten setzt, sollte Hash-Pinning nicht als alleinige Sperrlogik verwenden, sondern zusätzliche Kriterien ergänzen: Inhaltsbasierte Prüfsummen, Reproduzierbarkeitschecks, Validierung der heruntergeladenen Artefakte sowie eine klare Trennung zwischen Signaturidentität und Objekt-ID. Außerdem lohnt es sich, bei Tools zur Supply-Chain-Automation darauf zu achten, ob sie Commit-Hashes direkt als Schlüssel für Deduplication oder Provenance nutzen oder ob sie zuvor eine Normalisierung durchführen. In einem zukünftigen Reifegrad werden Forges die Signaturkodierung vor der Hash-Vertrauensbildung vereinheitlichen; damit sinkt die Angriffsoberfläche „malleierte, aber verifizierte“ Objekte. Bis dahin bleibt die Empfehlung: Hashes sind hilfreich, aber sie sind nicht automatisch ein eindeutiger Inhaltsbeweis über alle Re-Encodings hinweg.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- NIEDLICHER BEGLEITER: Eilik ist der ideale Begleiter für Kinder und Erwachsene, die Haustiere, Spiele und intelligente Roboter lieben. Mit vielen Emotionen, Bewegungen und interaktiven Funktionen.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "GitHub „Verified“: Signaturen lassen Hashes neu schreiben – Risiko für Hash-Blocklisten" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "GitHub „Verified“: Signaturen lassen Hashes neu schreiben – Risiko für Hash-Blocklisten" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »GitHub „Verified“: Signaturen lassen Hashes neu schreiben – Risiko für Hash-Blocklisten« bei Google Deutschland suchen, bei Bing oder Google News!