Git Hash Chain Malleability

Stellen Sie sich das Internet als eine riesige, weltweite Bibliothek vor, in der jedes Buch, jedes Rezept und jede Bedienungsanleitung in einem digitalen Tresor gespeichert ist. Um diese Bibliothek organisiert zu halten, erhält jeder einzelne Gegenstand eine einzigartige ID-Karte, die aus einem speziellen Code besteht. In der Welt der Softwareentwicklung wird dieses System Git genannt. Betrachten Sie einen „Commit“ als eine Momentaufnahme eines Projekts zu einem bestimmten Zeitpunkt – wie das Fotografieren einer Lego-Burg, die Sie gerade eben gebaut haben. Um sicherzustellen, dass niemand hineinschleicht und einen Stein gegen einen aus Plastik austauscht, können Entwickler ihre Fotos mit einem digitalen Siegel versehen, wie ein Wachssiegel auf einem Brief. Dieses Siegel beweist: „Ja, ich habe das gebaut, und niemand hat es verändert.“

Die große Idee hinter diesem System ist Vertrauen durch Einzigartigkeit. Wenn Sie den einzigartigen ID-Code des Fotos haben, sollten Sie in der Lage sein, genau dieses Foto zu finden und zu wissen, dass es nicht verändert wurde. Es ist wie zu sagen: „Wenn die ID-Karte ‚Burg A‘ sagt, dann ist ‚Burg A‘ das einzige Ding auf der Welt, das dieser Beschreibung entspricht.“ Dieses Vertrauen ist so stark, dass Computer diese ID-Codes verwenden, um automatisch zu prüfen, ob Software sicher ist, um bestimmte Versionen von Code festzuschreiben, damit sie nicht kaputtgehen, und um genau zu beweisen, wer was gebaut hat. Wenn der ID-Code einzigartig und unveränderlich ist, funktioniert das gesamte System wie eine gut geölte Maschine. Aber was passiert, wenn jemand ein perfekt gutes, signiertes Foto nehmen, das Wachssiegel ein winziges bisschen verändern und ein brandneues ID-Kärtchen erhalten kann, das immer noch beweist, dass das Foto echt ist? Das ist die Frage, die dieses Paper stellt.

Der Große Digitale Identitätswechsel

In diesem Paper hat ein Forscher namens Jacob Ginesin einen hinterlistigen Trick entdeckt, der die „Ein Foto, eine ID“-Regel in Git bricht. Er zeigte, dass ein Angreifer, ohne die geheimen Signaturschlüssel stehlen oder die Mathematik hinter den digitalen Siegeln knacken zu müssen, eine zweite, völlig andere ID-Karte für exakt dieselbe Software erstellen kann.

Hier ist der Zaubertrick: Der Angreifer nimmt einen signierten Commit (ein Foto mit einem Wachssiegel) und passt das Siegel so an, dass es für einen Computer zwar anders aussieht, für einen Menschen aber exakt dasselbe bedeutet. Es ist, als würde man ein Wachssiegel nehmen, es in eine leicht andere Form pressen oder dieselbe Nachricht auf einem Stück Papier schreiben, aber eine andere Schriftart verwenden. Der Inhalt des Fotos hat sich überhaupt nicht geändert – die Lego-Burg ist identisch. Das Siegel beweist immer noch die Identität des Autors. Aber weil das „Aussehen“ des Siegels sich geändert hat, generiert der Computer einen völlig neuen ID-Code dafür.

Der beängstigende Teil? Die Computersysteme, die diese IDs prüfen (wie GitHub), sagen: „Hey, dieses Siegel ist gültig! Dies ist ein verifizierter Commit!“ und verleihen ihm ein glänzendes grünes „Verified“-Abzeichen. Nun haben Sie zwei verschiedene ID-Karten für exakt dieselbe Lego-Burg. Die eine sagt „Burg A“, die andere sagt „Burg B“. Beide wurden von derselben Person signiert, und beide sind als „Verifiziert“ markiert.

Die Drei Wege, das System auszutricksen

Das Paper erklärt drei verschiedene Arten, diesen Trick auszuführen, je nachdem, welche Art von digitalem Siegel verwendet wird:

1. Der Mathe-Flip (für ECDSA): Stellen Sie sich eine Zahlenlinie vor, auf der Sie eine Zahl haben, sagen wir 5. In diesem speziellen Mathematikspiel sind die Zahl 5 und die Zahl „Gesamtsumme minus 5“ tatsächlich dasselbe. Der Angreifer dreht einfach die Zahl auf dem Siegel um. Es sieht anders aus, aber die Mathematik sagt, dass es immer noch eine gültige Signatur ist.
2. Die versteckte Notiz (für RSA und EdDSA): Stellen Sie sich einen versiegelten Brief vor. Das Siegel bedeckt die Hauptbotschaft, aber es gibt eine kleine Tasche auf der Rückseite, die nicht versiegelt ist. Der Angreifer schiebt eine winzige, harmlose Notiz in diese Tasche. Die Hauptbotschaft bleibt unberührt und das Siegel ist immer noch gültig, aber der Brief hat nun ein etwas anderes Gewicht und eine andere Form, was die ID-Karte verändert.
3. Die ausgefallene Schriftart (für S/MIME): Stellen Sie sich vor, Sie schreiben eine Zahl wie „32“. Sie können „32“ schreiben oder „0x20“. Beides bedeutet dasselbe, aber die eine ist die „Standard“-Art und die andere die „ausgefallene“ Art. Der Angreifer schreibt die Zahl in der ausgefallenen Art um. Der Computer, der den Brief prüft (GitHub), ist etwas nachsichtig und akzeptiert die ausgefallene Schriftart, aber ein strengerer Computer (Ihr lokaler Laptop) könnte verwirrt sein und sagen: „Warte, das ist nicht die Standard-Art!“

Warum das wichtig ist: Das „Geister“-Problem

Sie denken vielleicht: „Na und? Wenn die Burg dieselbe ist, wen kümmert das?“ Aber in der digitalen Welt ist die ID-Karte die Burg.

• Das Türsteher-Problem: Stellen Sie sich einen Türsteher im Club vor, der eine Liste mit gesperrten IDs hat. Wenn Sie gesperrt sind, kommen Sie nicht rein. Aber wenn der Angreifer eine „Geister-ID“ für dieselbe Person erstellt, die nicht auf der Sperrliste steht, lässt der Türsteher sie herein. Der Angrever kann bösartigen Code an Sicherheitsfiltern vorbeischleusen, indem er einfach die ID-Karte ändert.
• Das Spiegel-Problem: Stellen Sie sich zwei Spiegel vor, die sich gegenüberstehen. Einer zeigt die echte Burg; der andere zeigt eine „Geister-Burg“, die identisch aussieht, aber einen anderen Namen hat. Wenn Sie in den falschen Spiegel schauen, glauben Sie vielleicht, die Originalburg zu sehen, aber Sie sehen eigentlich eine Kopie, die der Angreifer kontrolliert.
• Die gebrochene Kette: Da jede neue Lego-Burg in einer Kette auf der vorherigen aufgebaut wird, ändert das Ändern der ID einer Burg die ID aller Burgen, die danach gebaut wurden. Dies erzeugt einen „Fork“ (eine Abzweigung) in der Historie. Man endet mit zwei parallelen Zeitlinien: einer mit der ursprünglichen ID und einer mit der Geister-ID. Beide sehen echt aus, beide sind signiert, aber sie sind unterschiedlich.

Das Urteil

Das Paper beweist, dass das „Verified“-Abzeichen auf einem Commit-Hash keine eindeutige Garantie für den Inhalt ist. Es ist wie ein „Verifiziert“-Stempel in einem Reisepass, der nicht garantiert, dass Sie die einzige Person mit diesem Gesicht sind; er garantiert nur, dass der Stempel echt ist.

Der Autor entwickelte ein Tool, das diesen Trick automatisch bei jedem signierten Commit anwenden kann. Er testete es auf GitHub, und die Seite akzeptierte die „Geister“-Commits bereitwillig und gab ihnen ihre eigenen „Verified“-Abzeichen. Das bedeutet, dass Systeme, die sich auf diese ID-Karten verlassen, um böswillige Akteure zu blockieren, Softwareversionen zu sperren oder zu beweisen, wer was gebaut hat, angreifbar sind. Die Lösung besteht nicht darin, das Signieren zu stoppen, sondern darin, sicherzustellen, dass die Computer, die die Siegel prüfen, streng genug sind, um zu sagen: „Nein, das ist nicht exakt dasselbe Siegel, das wir zuvor gesehen haben“, und um den tatsächlichen Inhalt zu prüfen, statt nur die ID-Karte.

Kurz gesagt: Ein signierter Commit ist ein Versprechen, aber das Paper zeigt, dass das Versprechen so formuliert werden kann, dass eine „Geisterversion“ seiner selbst entsteht, die die Systeme austrickst, die uns eigentlich schützen sollen.