Open Source im professionellen Einsatz

Linus Torvalds zu SHA-1 und Git

27.02.2017

Nachdem Google am 23. Februar eine Technik vorstellte, um SHA-1-Kollisionen künstlich hervorzurufen, stellt sich auch die Frage nach der SHA-1-Nutzung von Git. Linus Torvalds gibt sich dennoch entspannt.

539

160-Bit-SHA-1-Hashes kommen bei Git zum Einsatz, um die Integrität von Dateien zu sichern. Ändert ein Angreifer eine Datei A, ändert sich auch automatisch deren Hash. Das fällt gewöhnlich auf. Kollisionen hebeln dieses Prinzip aus. Mit ihnen lässt sich eine Datei B künstlich erzeugen, die einen anderen Inhalt als Datei A besitzt, aber den identischen SHA-1-Hash (Secure Hash Algorithm). Prüft eine Infrastruktur also nur die Hashes und vergleicht nicht die Inhalte selbst, lässt sich so eine Datei mit geänderten Inhalten unterschieben.

Git verwendet solche SHA-1-Hashes, um die Integrität und Unterscheidbarkeit der Dateien zu gewährleisten. Nun könnte das Versionskontrollsystem einfach auf einen stärkeren Hash wie SHA-256 wechseln, hätte Linus Torvalds es nicht 2005 explizit abgelehnt, eine Infrastruktur für Git zu schaffen, die so einen einfachen Wechsel erlaubt. Seine Argumentation damals: "Git verwendet SHA-1 schlicht als einen Hash und nicht notwendigerweise als einen kryptografisch sicheren." Git wolle mit Hashes lediglich doppelte Datei-Inhalte verhindern. Alles in allem, schrieb Torvalds in einer Antwort auf den Vorschlag des Bürgerrechtlers John Gilmore, gäbe es nichts, worüber man sich Sorgen machen müsse.

Nun kam das Thema erneut auf, angestoßen durch Ex-Debian-Entwickler Joey Hess. Torvalds wies darauf hin, dass sich anders als bei Googles PDF-Demonstration in Git nicht so einfach ein Zwilling aus guten und bösen Objekten erzeugen lasse. Schuld daran sei unter anderem, dass Git nicht nur die Daten hashe, sondern diesen auch ein Type/Length-Feld voranstelle, was das Erzeugen von Kollisionen wesentlich erschwere. Der Angreifer müsse zusätzlich das "size field" im Header einer Datei manipulieren. Bei den PDFs, die Google verwendet habe, ginge das nicht, weil sie einen fixen Header verwenden.

Tatsächlich erschweren die vorangestellten Daten das Erzeugen einer Kollision, wie Joey Hess herausfand. Es brauche zudem laut Google Paper 6500 CPU-Jahre plus 110 GPU-Jahre um valide kollidierende Git-Objekte zu erzeugen. Ob das akzeptable Kosten seien, um eine Backdoor im Kernel zu platzieren, sei die Frage, so Hess.

Zusätzlich zu diesen Kosten, antwortete Torvalds, bräuchte ein Angreifer auch soziales Kapital, um jemanden zu finden, der nicht nur ein Patch appliziere, sondern auch ein "git pull" ausführe, um die Änderungen in den Tree zu holen. Und dann ließen sich solche Änderungen mit "git fsck" zudem recht einfach entdecken. Der Befehl laufe zum Beispiel automatisch jede Nacht auf Kernel.org.

Allerdings gab Torvalds zu, könne man recht einfach zusätzliche Sanity Checks integrieren, um das Verstecken von zufälligen Daten deutlich zu erschweren. Hess schlug daraufhin vor, dass auch "git show", "git merge" und "git pull" Alarm schlagen, wenn sie, wie bislang "git fsck", verborgene Daten nach einem "NUL"-Eintrag entdecken. Das sieht Torvalds ähnlich, zum Zeitpunkt eines "fetch" könne man nach versteckten Daten suchen, aber auch nach Angriffsmustern fahnden.

Langfristig möchte auch Torvalds auf einen sicheren Hash migrieren, etwa SHA-3-256. Dennoch sieht er für SHA-1 das Ende noch nicht gekommen. Es sei recht einfach, solche Angriffe unbrauchbar zu machen, wenn sie aufwändig zu starten sind und zugleich einfach zu entdecken, so sein Resümee.

Ähnliche Artikel

comments powered by Disqus

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.