Problematischer ist die Verwendung von SHA-1 zur Signatur ganzer Code-Zweige. [...] Zum einen gibt es Möglichkeiten, die SHA-1-Manipulation automatisch zu erkennen
Wie wird das in einem Szenario funktionieren, wie:
1. Angreifer erzeugt zwei Commits
- "fixed some bug" - "added better .png icon"
2. Angreifer stellt Merge Request
3. Review findet alles ok
4. Angreifer erzeugt zwei Commits
- "added backdoor" - "added better .png icon"
wobei der zweite eine Hashcollision ausloest und insgesamt dann die selbe Commit-ID wie bei 1. entsteht
5. Maintainer merged das Patchset mit der Backdoor
Von slalomsk8er am Mo, 27. Februar 2017 um 14:59 #
5. Maintainer hat 1. Commit bereits gemerged und der neuere wird von Git als identisch also ein Duplikat erkannt und ignoriert.
Das selbe mit Dateien - Git behält das ältere "Original" und verwirft das neuere "identische" Exemplar. Dateien sind übrigens noch zusätzlich zum Hash durch die Grösse geprüft - noch ist keine Kollision bekannt, die beides kann.
Von slalomsk8er am Mo, 27. Februar 2017 um 14:54 #
Ein entscheidendes Detail warum Git im Gegensatz zu SVN kein Problem mit dieser Kollision hat, ist weil Git neben dem SHA-1 auch noch die Grösse der Datei Notiert um sie zu identifizieren.
Diese Kollision erzeugt unterschiedlich grosse Dateien.
Weiter verstehe ich die Kollision so, dass man an beiden Dateien herum Manipulieren muss, bis der Hash gleich ist. Also keine direkte Gefahr für existierende Dateien und deren Hash.
Du meinst wahrscheinlich das im checkout index die Groesse gespeichtert ist? Im reinen git data model wird die file groesse nur einmal gespeichert und kann mit der Attacke veraendert werden. Der Vergleich zum index koennte dann denn Fehler finden...
Wie wird das in einem Szenario funktionieren, wie:
1. Angreifer erzeugt zwei Commits
- "fixed some bug"
- "added better .png icon"
2. Angreifer stellt Merge Request
3. Review findet alles ok
4. Angreifer erzeugt zwei Commits
- "added backdoor"
- "added better .png icon"
wobei der zweite eine Hashcollision ausloest und insgesamt dann die selbe Commit-ID wie bei 1. entsteht
5. Maintainer merged das Patchset mit der Backdoor
5. Maintainer hat 1. Commit bereits gemerged und der neuere wird von Git als identisch also ein Duplikat erkannt und ignoriert.
Das selbe mit Dateien - Git behält das ältere "Original" und verwirft das neuere "identische" Exemplar.
Dateien sind übrigens noch zusätzlich zum Hash durch die Grösse geprüft - noch ist keine Kollision bekannt, die beides kann.
Nicht zu vergessen merged doch keiner einen Commit an dem die Nachricht
> - "added backdoor"
dran hängt
Das ist eine Frage des Verfahrens und setzt voraus, dass Reviewer == Maintainer.
Ein entscheidendes Detail warum Git im Gegensatz zu SVN kein Problem mit dieser Kollision hat, ist weil Git neben dem SHA-1 auch noch die Grösse der Datei Notiert um sie zu identifizieren.
Diese Kollision erzeugt unterschiedlich grosse Dateien.
Weiter verstehe ich die Kollision so, dass man an beiden Dateien herum Manipulieren muss, bis der Hash gleich ist.
Also keine direkte Gefahr für existierende Dateien und deren Hash.
Statt dessen wird ein Bug eingepflegt. Den man auf den ersten Blick nicht erkennt.
Du meinst wahrscheinlich das im checkout index die Groesse gespeichtert ist? Im reinen git data model wird die file groesse nur einmal gespeichert und kann mit der Attacke veraendert werden. Der Vergleich zum index koennte dann denn Fehler finden...
> Diese Kollision erzeugt unterschiedlich grosse Dateien.
entschuldigung, die beiden pdf dateien auf https://shattered.it/ sind gleichgroß und haben denselben hash
aber lieber erstmal was schreiben bevor man die details kennt!?
Ja, die sind gleich gross weil der Hersteller der beiden Dateien beide Dateien unter seiner Kontrolle hat?
"Torvalds ist heute nicht mehr aktiv an der Weiterentwicklung von Git beteiligt, ist aber wohl weiterhin der größte Kenner des Systems."
Wie kommst du auf das?
https://github.com/git/git/graphs/contributors
Seit 2012 hat er 12 Commits eingereicht