In che modo la recente collisione SHA-1 influisce su Git?

Recentemente un team di ricercatori ha generato due file con lo stesso hash SHA-1 ( https://shattered.it/ ).

Dato che Git usa questo hash per la sua memoria interna, in che misura questo tipo di attacco influenza Git?

Modifica, fine dicembre 2017: Git versione 2.16 sta gradualmente acquisendo interfacce interne per consentire diversi hash . C’è ancora molta strada da fare.


La risposta breve (ma insoddisfacente) è che i file di esempio non sono un problema per Git, ma potrebbero esserlo altri due (calcolati con cura).

Ho scaricato entrambi i file, shattered-1.pdf e shattered-2.pdf e li ho inseriti in un nuovo repository vuoto:

 macbook$ shasum shattered-* 38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-1.pdf 38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-2.pdf macbook$ cmp shattered-* shattered-1.pdf shattered-2.pdf differ: char 193, line 8 macbook$ git init Initialized empty Git repository in .../tmp/.git/ macbook$ git add shattered-1.pdf macbook$ git add shattered-2.pdf macbook$ git status On branch master Initial commit Changes to be committed: (use "git rm --cached ..." to unstage) new file: shattered-1.pdf new file: shattered-2.pdf 

Anche se i due file hanno lo stesso checksum SHA-1 (e sono visualizzati per lo più lo stesso, sebbene uno abbia uno sfondo rosso e l’altro abbia uno sfondo blu), ottengono diversi hash Git :

 macbook$ git ls-files --stage 100644 ba9aaa145ccd24ef760cf31c74d8f7ca1a2e47b0 0 shattered-1.pdf 100644 b621eeccd5c7edac9b7dcba35a8d5afd075e24f2 0 shattered-2.pdf 

Questi sono i due checksum SHA-1 per i file memorizzati in Git : uno è ba9aa... e l’altro è b621e... Né è 38762c... Ma- perché?

La risposta è che Git memorizza i file, non come se stessi, ma piuttosto come il blob letterale stringa, uno spazio vuoto, la dimensione del file decimalizzato e un byte NUL ASCII, e quindi i dati del file. Entrambi i file hanno esattamente le stesse dimensioni:

 macbook$ ls -l shattered-?.pdf ... 422435 Feb 24 00:55 shattered-1.pdf ... 422435 Feb 24 00:55 shattered-2.pdf 

quindi entrambi sono prefissati con il blob 422435\0 testo letterale blob 422435\0 (dove \0 rappresenta un byte singolo, un blob 422435\0 o un python di escape ottale nelle stringhe).

Forse sorprendentemente, o meno, se si conosce qualcosa su come viene calcolato SHA-1 – aggiungendo lo stesso prefisso a due file diversi che hanno comunque prodotto lo stesso checksum , ora producono risultati di checksum diversi .

La ragione per cui questo non dovrebbe sorprendere è che se il risultato finale del checksum non fosse squisitamente sensibile alla posizione , così come il valore, di ogni bit di input, sarebbe facile produrre collisioni su richiesta prendendo un file di input conosciuto e semplicemente ri -rannando alcuni dei suoi bit. Questi due file di input producono la stessa sum pur avendo un byte diverso in char 193, line 8 , ma questo risultato è stato raggiunto, secondo i ricercatori, provando oltre 9 quintilioni di input ( scala ridotta ). Per ottenere quel risultato, inserivano blocchi accuratamente selezionati di dati grezzi, in una posizione che controllavano, che avrebbero influenzato le somme, fino a quando non hanno trovato coppie di input che hanno provocato una collisione.

Aggiungendo l’intestazione del blob , Git ha spostato la posizione , distruggendo i 110-GPU-anni di calcolo in un singolo rutto più o meno accidentale.

Ora, sapendo che Git farà questo, potrebbero ripetere i loro calcoli di 110-GPU anni con input che iniziano con blob 422435\0 (a condizione che i loro blocchi sacrificali non vengano spinti troppo in giro e il numero effettivo di GPU- gli anni di calcolo necessari probabilmente varrebbero, poiché il processo è un po ‘ stocastico ). Verrebbero quindi creati due file diversi che potrebbero essere blob del blob . Questi due file ora avranno checksum SHA-1 diversi l’uno dall’altro, ma quando git add -ed, entrambi produrrebbero lo stesso checksum SHA-1.

In quel caso particolare, il primo file aggiunto avrebbe “vinto” lo slot. (Supponiamo che sia chiamato shattered-3.pdf .) Un Git abbastanza buono-non sono affatto sicuro che l’attuale Git sia così buono; vedere la risposta basata su esperimenti di Ruben su Come Git gestirà una collisione SHA-1 su un blob? shattered-3.pdf dovrebbe notare che git add shattered-4.pdf , tentando di aggiungere il secondo file, colliso con il primo-ma-diverso shattered-3.pdf e ti avviserà e fallirà il passo git add . In ogni caso non sarebbe ansible aggiungere entrambi questi file ad un singolo repository.

Ma prima, qualcuno deve spendere molto più tempo e denaro per calcolare la nuova collisione di hash.

Forse la risposta di Linus potrebbe far luce:

Qualcuno di IIRC ha lavorato sulla parametrizzazione delle assunzioni SHA1 di git, quindi un repository potrebbe usare un hash più sicuro. Quanto è lontano? Ci sono ancora molte costanti “40” in git.git HEAD.

Non penso che tu voglia necessariamente cambiare la dimensione dell’hash. È ansible utilizzare un hash diverso e utilizzare solo gli stessi 160 bit da esso.

Poiché ora abbiamo collisioni in file PDF validi, è probabile che le collisioni nel commit git valido e gli oggetti ad albero possano essere costruiti.

Non ho ancora visto l’attacco, ma git in realtà non ha solo cancellato i dati, ma antepone un campo tipo / lunghezza. Questo di solito tende a rendere gli attacchi di collisione molto più difficili, perché devi rendere uguali anche le dimensioni risultanti o devi anche modificare il campo delle dimensioni nell’intestazione.

i pdf non hanno questo problema, hanno un’intestazione fissa e puoi aggiungere arbitrariamente dati silenziosi al centro che non vengono mostrati.

Quindi i pdf rappresentano un vettore di attacco molto migliore, proprio perché sono un formato di dati abbastanza opaco. Git ha dei dati opachi in alcuni punti (ad esempio nascondiamo le cose negli oggetti commit, ma per definizione i dati opachi sono piuttosto secondari.

Detto in altro modo: dubito che il cielo stia cadendo per git come strumento di gestione del controllo del codice sorgente. Vogliamo migrare verso un altro hash? Sì. E ‘”game over” per SHA1 come la gente vuole dire? Probabilmente no.

Non ho visto i dettagli dell’attacco, ma scommetto

(a) il fatto che abbiamo una codifica di dimensioni separate rende molto più difficile da fare su oggetti git in primo luogo

(b) probabilmente possiamo facilmente aggiungere alcuni controlli extra di sanità ai dati opachi che abbiamo, per rendere molto più difficile hide i dati casuali da cui questi attacchi dipendono quasi sempre.

Linus

Fonte: https://marc.info/?l=git&m=148787047422954