In che modo Git gestirà una collisione SHA-1 su un blob?

Questo probabilmente non è mai successo nel mondo reale e potrebbe non accadere mai, ma consideriamo questo: diciamo che hai un repository git, fai un commit e diventa molto sfortunato: uno dei blob finisce per avere lo stesso SHA-1 come un altro che è già nel tuo repository. La domanda è: come potrebbe gestirlo Git? Semplicemente fallire? Trova un modo per collegare i due BLOB e verificare quale è necessario in base al contesto?

Più un rompicapo che un vero problema, ma ho trovato il problema interessante.

Ho fatto un esperimento per scoprire esattamente come si sarebbe comportato Git in questo caso. Questo è con la versione 2.7.9 ~ rc0 + next.20151210 (versione Debian). Fondamentalmente ho appena ridotto la dimensione dell'hash da 160-bit a 4-bit applicando il seguente diff e ricostruendo git:

--- git-2.7.0~rc0+next.20151210.orig/block-sha1/sha1.c
+++ git-2.7.0~rc0+next.20151210/block-sha1/sha1.c
@@ -246,6 +246,8 @@ void blk_SHA1_Final(unsigned char hashou
    blk_SHA1_Update(ctx, padlen, 8);

    /* Output hash */
-   for (i = 0; i < 5; i++)
-       put_be32(hashout + i * 4, ctx->H[i]);
+   for (i = 0; i < 1; i++)
+       put_be32(hashout + i * 4, (ctx->H[i] & 0xf000000));
+   for (i = 1; i < 5; i++)
+       put_be32(hashout + i * 4, 0);
 }

Poi ho fatto alcuni commit e ho notato quanto segue.

1. Se esiste già un BLOB con lo stesso hash, non riceverai alcun avviso. Tutto sembra andare bene, ma quando spingi, qualcuno clona o ritorni, perderai l'ultima versione (in linea con quanto spiegato sopra).
2. Se esiste già un oggetto albero e si crea un BLOB con lo stesso hash: tutto sembrerà normale, finché non si tenta di spingere o qualcuno clona il proprio repository. Quindi vedrai che il repository è danneggiato.
3. Se esiste già un oggetto commit e si crea un BLOB con lo stesso hash: uguale a # 2 - danneggiato
4. Se esiste già un BLOB e si crea un oggetto commit con lo stesso hash, fallirà durante l'aggiornamento di "ref".
5. Se esiste già un BLOB e si crea un oggetto albero con lo stesso hash. Non funzionerà durante la creazione del commit.
6. Se esiste già un oggetto ad albero e si crea un oggetto commit con lo stesso hash, fallirà durante l'aggiornamento di "ref".
7. Se esiste già un oggetto albero e si crea un oggetto albero con lo stesso hash, tutto sembrerà ok. Ma quando commetti, tutto il repository farà riferimento all'albero sbagliato.
8. Se esiste già un oggetto commit e si crea un oggetto commit con lo stesso hash, tutto sembrerà ok. Ma quando esegui il commit, il commit non verrà mai creato e il puntatore HEAD verrà spostato su un vecchio commit.
9. Se esiste già un oggetto commit e si crea un oggetto albero con lo stesso hash, fallirà durante la creazione del commit.

Per # 2 in genere si verifica un errore del genere quando si esegue "git push":

error: object 0400000000000000000000000000000000000000 is a tree, not a blob
fatal: bad blob object
error: failed to push some refs to origin

o:

error: unable to read sha1 file of file.txt (0400000000000000000000000000000000000000)

se si elimina il file e si esegue "git checkout file.txt".

Per # 4 e # 6, in genere si verifica un errore come questo:

error: Trying to write non-commit object
f000000000000000000000000000000000000000 to branch refs/heads/master
fatal: cannot update HEAD ref

quando si esegue "git commit". In questo caso, in genere puoi semplicemente digitare nuovamente "git commit" poiché ciò creerà un nuovo hash (a causa del timestamp modificato)

Per # 5 e # 9, in genere viene visualizzato un errore come questo:

fatal: 1000000000000000000000000000000000000000 is not a valid 'tree' object

quando si esegue "git commit"

Se qualcuno prova a clonare il tuo repository corrotto, in genere vedrà qualcosa del tipo:

git clone (one repo with collided blob,
d000000000000000000000000000000000000000 is commit,
f000000000000000000000000000000000000000 is tree)

Cloning into 'clonedversion'...
done.
error: unable to read sha1 file of s (d000000000000000000000000000000000000000)
error: unable to read sha1 file of tullebukk
(f000000000000000000000000000000000000000)
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry the checkout with 'git checkout -f HEAD'

Ciò che "mi preoccupa" è che in due casi (2,3) il repository si corrompe senza alcun preavviso e in 3 casi (1,7,8), tutto sembra ok, ma il contenuto del repository è diverso da quello che ti aspetti essere. Le persone che clonano o tirano avranno un contenuto diverso da quello che hai. I casi 4,5,6 e 9 sono ok, poiché si fermerà con un errore. Suppongo che sarebbe meglio se fallisse con un errore almeno in tutti i casi.

Risposta originale (2012) (vedi shattered.iocollisione SHA1 2017 di seguito)

Quella vecchia (2006) risposta di Linus potrebbe essere ancora rilevante:

No. Se ha lo stesso SHA1, significa che quando riceviamo l'oggetto dall'altra estremità, non sovrascriveremo l'oggetto che già abbiamo.

Quindi, ciò che accade è che se mai vedessimo una collisione, l'oggetto "precedente" in un particolare repository finirà sempre per prevalere. Ma si noti che "precedente" è ovviamente per repository, nel senso che la rete di oggetti git genera un DAG che non è completamente ordinato, quindi mentre diversi repository saranno d'accordo su ciò che è "precedente" nel caso di antenati diretti, se il l'oggetto è arrivato attraverso rami separati e non direttamente correlati, due diversi repository potrebbero ovviamente aver ottenuto i due oggetti in ordine diverso.

Tuttavia, la "precedenza ignorerà" è molto ciò che si vuole dal punto di vista della sicurezza: si ricorda che il modello git è che si dovrebbe in primo luogo fiducia solo il vostro proprio repository.
Quindi, se fai un " git pull", i nuovi oggetti in arrivo sono per definizione meno affidabili degli oggetti che hai già, e come tale sarebbe sbagliato permettere a un nuovo oggetto di sostituirne uno vecchio.

Quindi hai due casi di collisione:

• del tipo involontario , in cui in qualche modo sei molto sfortunato, e due file finiscono per avere lo stesso SHA1.
  A quel punto, ciò che accade è che quando si esegue il commit di quel file (o si esegue un " git-update-index" per spostarlo nell'indice, ma non ancora eseguito il commit), verrà calcolato l'SHA1 dei nuovi contenuti, ma poiché corrisponde a un vecchio oggetto, non verrà creato un nuovo oggetto e il commit-o-index finirà per puntare al vecchio oggetto .
  Non noterai immediatamente (poiché l'indice corrisponderà al vecchio oggetto SHA1, e ciò significa che qualcosa del tipo "git diff " utilizzerà la copia di cui è stato eseguito il checkout), ma se fai mai un diff a livello di albero (o fai un clone o pull, o forzare un checkout) noterai improvvisamente che quel file è cambiato in qualcosacompletamente diverso da quello che ti aspettavi.
  Quindi noterai questo tipo di collisione abbastanza rapidamente. ") e quindi insegna a git sulla magia SHA1 che si è dimostrata pericolosa.
  Nelle notizie correlate, la domanda è cosa fare in caso di collisione involontaria.
  Prima di tutto, lasciatemi ricordare alla gente che il tipo di collisione involontaria è davvero dannatamente improbabile, quindi probabilmente non lo vedremo mai nella storia completa dell'universo.
  Ma se succede, non è la fine del mondo: quello che molto probabilmente dovresti fare è semplicemente cambiare il file che si è leggermente scontrato e forzare un nuovo commit con i contenuti modificati (aggiungi un commento che dice "/* This line added to avoid collision */
  Quindi, nel giro di un paio di milioni di anni, forse dovremo aggiungere uno o due valori SHA1 "avvelenati" a git. È molto improbabile che si tratti di un problema di manutenzione;)

• Il tipo di collisione dell'attaccante perché qualcuno ha rotto (o forzato brutalmente) SHA1.
  Questo è chiaramente molto più probabile del tipo involontario, ma per definizione è sempre un repository "remoto". Se l'attaccante avesse accesso al repository locale, avrebbe modi molto più semplici per rovinarti.
  Quindi, in questo caso, la collisione non è assolutamente un problema : otterrai un repository "cattivo" diverso da quello che intendeva l'attaccante, ma dal momento che non userai mai effettivamente il suo oggetto in collisione, non è letteralmente diverso dal attaccante che non ha trovato alcuna collisione, ma semplicemente usando l'oggetto che hai già avuto (cioè è equivalente al 100% alla collisione "banale" dello stesso file che genera lo stesso SHA1).

La domanda sull'uso di SHA-256 è regolarmente menzionata, ma per ora non agire (2012).
Nota: a partire dal 2018 e Git 2.19 , il codice è in fase di refactoring per utilizzare SHA-256.

Nota (Humor): è possibile forzare un commit su un particolare prefisso SHA1 , con il progetto gitbrute di Brad Fitzpatrick ( bradfitz) .

gitbrute brute-force una coppia di timestamp autore + committer in modo tale che il commit git risultante abbia il prefisso desiderato.

Esempio: https://github.com/bradfitz/deadbeef

Daniel Dinnyes sottolinea nei commenti a 7.1 Git Tools - Revision Selection , che include:

Esiste una maggiore probabilità che ogni membro del team di programmazione venga attaccato e ucciso dai lupi in incidenti non collegati nella stessa notte.

Anche di recente (febbraio 2017) ha shattered.iodimostrato la possibilità di provocare una collisione SHA1:
(vedi molto di più nella mia risposta separata , incluso il post di Google+ di Linus Torvalds)

• a / richiede ancora oltre 9.223.372.036.854.775.808 calcoli SHA1. Ciò ha portato la potenza di elaborazione equivalente a 6.500 anni di calcoli a CPU singola e 110 anni di calcoli a GPU singola.
• b / forgia un file (con lo stesso SHA1), ma con il vincolo aggiuntivo il suo contenuto e le sue dimensioni produrrebbe lo stesso SHA1 (una collisione sul solo contenuto non è sufficiente): vedi " Come viene calcolato l'hash git? ") : un BLA SHA1 viene calcolato in base al contenuto e alle dimensioni .

Vedi " Durata della vita delle funzioni hash crittografiche " di Valerie Anita Aurora per ulteriori informazioni.
In quella pagina, osserva:

Google ha trascorso 6500 anni di CPU e 110 anni di GPU per convincere tutti che dobbiamo smettere di usare SHA-1 per applicazioni critiche per la sicurezza.
Anche perché è stato bello

Vedi di più nella mia risposta separata di seguito .

Secondo Pro Git :

Se ti capita di eseguire il commit di un oggetto con hash sullo stesso valore SHA-1 di un oggetto precedente nel tuo repository, Git vedrà l'oggetto precedente già nel tuo database Git e supporrà che sia già stato scritto. Se provi a ricontrollare quell'oggetto ad un certo punto, otterrai sempre i dati del primo oggetto.

Quindi non fallirebbe, ma non salverebbe nemmeno il tuo nuovo oggetto.
Non so come sarebbe apparire sulla riga di comando, ma sarebbe sicuramente confuso.

Un po 'più in basso, lo stesso riferimento tenta di illustrare la probabilità di una tale collisione:

Ecco un esempio per darti un'idea di cosa sarebbe necessario per ottenere una collisione SHA-1. Se tutti i 6,5 miliardi di umani sulla Terra stessero programmando, e ogni secondo, ognuno produceva codice che era l'equivalente dell'intera storia del kernel Linux (1 milione di oggetti Git) e lo spingeva in un enorme repository Git, ci sarebbero voluti 5 anni quel repository conteneva abbastanza oggetti da avere una probabilità del 50% di una singola collisione di oggetti SHA-1. Esiste una maggiore probabilità che ogni membro del team di programmazione venga attaccato e ucciso dai lupi in incidenti non collegati nella stessa notte.

Per aggiungere alla mia precedente risposta del 2012 , ora c'è (febbraio 2017, cinque anni dopo), un esempio di effettiva collisione SHA-1 con shattered.io , in cui è possibile creare due file PDF in collisione: ovvero ottenere un SHA- 1 firma digitale sul primo file PDF che può anche essere abusata come firma valida sul secondo file PDF.
Vedi anche " Alla porta della morte da anni, la funzione SHA1 ampiamente usata è ora morta ", e questa illustrazione .

Aggiornamento 26 febbraio: Linus ha confermato i seguenti punti in un post di Google+ :

(1) Prima di tutto - il cielo non sta cadendo. C'è una grande differenza tra l'uso di un hash crittografico per cose come la firma di sicurezza e l'uso di uno per generare un "identificatore di contenuto" per un sistema indirizzabile al contenuto come git.

(2) In secondo luogo, la natura di questo particolare attacco SHA1 significa che in realtà è abbastanza facile mitigarlo e che sono già stati pubblicati due set di patch per tale mitigazione.

(3) E infine, c'è in realtà una transizione ragionevolmente semplice verso qualche altro hash che non romperà il mondo - o persino vecchi repository git.

Per quanto riguarda tale transizione, vedi Git 2.16 del primo trimestre del 2018 aggiungendo una struttura che rappresenta l'algoritmo hash. È iniziata l'implementazione di tale transizione.

A partire da Git 2.19 (Q3 2018) , Git ha scelto SHA-256 come NewHash ed è in procinto di integrarlo nel codice (il che significa che SHA1 è ancora l'impostazione predefinita (Q2 2019, Git 2.21), ma SHA2 sarà il successore)

Risposta originale (25 febbraio) Ma:

• Ciò consente di forgiare un BLOB, tuttavia lo SHA-1 dell'albero cambierebbe ancora poiché la dimensione del BLOB forgiato potrebbe non essere la stessa di quella originale: vedere " Come viene calcolato l'hash git? "; un BLA SHA1 viene calcolato in base al contenuto e alle dimensioni .
  Essa ha ancora qualche problema per git-svnse . O meglio con lo stesso svn , come visto qui .
• Come ho detto nella mia risposta originale , il costo di un simile tentativo è ancora proibitivo per ora (6.500 anni di CPU e 100 anni di GPU) Vedi anche Valerie Anita Aurora in " Durata della vita delle funzioni di hash crittografiche ".
• Come commentato prima, non si tratta di sicurezza o fiducia, ma di integrità dei dati (deduplicazione e rilevamento degli errori) che possono essere facilmente rilevati da un git fsck, come menzionato oggi da Linus Torvalds . git fsckavviserebbe di un messaggio di commit con dati opachi nascosti dopo un NUL(sebbene NULnon sia sempre presente in un file fraudolento ).
  Non tutti si transfer.fsckaccendono, ma GitHub lo fa: qualsiasi spinta sarebbe interrotta nel caso di un oggetto non valido o di un collegamento interrotto. Anche se ... c'è un motivo per cui questo non è attivato di default .
• un file pdf può contenere dati binari arbitrari che è possibile modificare per generare un SHA-1 in collisione, al contrario del codice sorgente contraffatto.
  Il vero problema nella creazione di due repository Git con lo stesso head commette hash e contenuti diversi. E anche allora, l' attacco rimane contorto .
• Linus aggiunge :

  Il punto centrale di un SCM è che non si tratta di un evento singolo, ma di una storia continua. Ciò significa anche che un attacco riuscito deve funzionare nel tempo e non essere rilevabile.
  Se riesci a ingannare una SCM una volta, inserisci il tuo codice e verrà rilevato la prossima settimana, in realtà non hai fatto nulla di utile. Ti sei solo bruciato.

Joey Hess prova quei pdf in un repository Git e ha scoperto :

Ciò include due file con lo stesso SHA e le stesse dimensioni, che ottengono BLOB diversi grazie al modo in cui git antepone l'intestazione al contenuto.

joey@darkstar:~/tmp/supercollider>sha1sum  bad.pdf good.pdf 
d00bbe65d80f6d53d5c15da7c6b4f0a655c5a86a  bad.pdf
d00bbe65d80f6d53d5c15da7c6b4f0a655c5a86a  good.pdf
joey@darkstar:~/tmp/supercollider>git ls-tree HEAD
100644 blob ca44e9913faf08d625346205e228e2265dd12b65    bad.pdf
100644 blob 5f90b67523865ad5b1391cb4a1c010d541c816c1    good.pdf

Mentre l'aggiunta di dati identici a questi file in collisione genera altre collisioni, il anteporre i dati no.

Quindi il vettore principale dell'attacco (forgiare un commit) sarebbe :

• Genera un oggetto commit regolare;
• usa l'intero oggetto commit + NUL come prefisso scelto e
• utilizzare l'attacco di collisione con prefisso identico per generare oggetti buoni / cattivi in ​​collisione.
• ... e questo è inutile perché gli oggetti di commit buoni e cattivi puntano ancora sullo stesso albero!

Inoltre, puoi già e rilevare attacchi di collisione crittoanalitici contro SHA-1 presenti in ogni file con cr-marcstevens/sha1collisiondetection

L'aggiunta di un controllo simile in Git stesso avrebbe un costo di calcolo .

Al cambio dell'hash, commenti Linux :

La dimensione dell'hash e la scelta dell'algoritmo di hash sono problemi indipendenti.
Quello che probabilmente faresti è passare a un hash a 256 bit, usarlo internamente e nel database git nativo, e quindi per impostazione predefinita mostrare l'hash solo come una stringa esadecimale di 40 caratteri (un po 'come il modo in cui già abbreviamo le cose in molte situazioni).
In questo modo gli strumenti intorno a git non vedono nemmeno il cambiamento a meno che non vengano passati alcuni " --full-hash" argomenti (o " --abbrev=64" o altro - il default è che abbreviamo in 40).

Tuttavia, un piano di transizione (da SHA1 a un'altra funzione hash) sarebbe ancora complesso , ma studiato attivamente.
Una convert-to-object_idcampagna è in corso :

Aggiornamento del 20 marzo: GitHub dettaglia un possibile attacco e la sua protezione :

I nomi SHA-1 possono essere assegnati fiducia attraverso vari meccanismi. Ad esempio, Git ti consente di firmare crittograficamente un commit o un tag. In questo modo si firma solo l'oggetto commit o tag stesso, che a sua volta punta ad altri oggetti contenenti i dati del file effettivo utilizzando i loro nomi SHA-1. Una collisione in quegli oggetti potrebbe produrre una firma che appare valida, ma che punta a dati diversi da quelli previsti dal firmatario. In tale attacco il firmatario vede solo la metà della collisione e la vittima vede l'altra metà.

Protezione:

Il recente attacco utilizza tecniche speciali per sfruttare le debolezze dell'algoritmo SHA-1 che trovano una collisione in molto meno tempo. Queste tecniche lasciano uno schema nei byte che può essere rilevato quando si calcola l'SHA-1 di una delle due metà di una coppia in collisione.

GitHub.com ora esegue questo rilevamento per ogni SHA-1 che calcola e interrompe l'operazione se ci sono prove che l'oggetto è la metà di una coppia in collisione. Ciò impedisce agli aggressori di utilizzare GitHub per convincere un progetto ad accettare la metà "innocente" della loro collisione, oltre a impedire loro di ospitare la metà malvagia.

Vedi " sha1collisiondetection" di Marc Stevens

Ancora una volta, con Git 2.16 del primo trimestre del 2018 che aggiunge una struttura che rappresenta l'algoritmo di hash, è iniziata l'implementazione di una transizione a un nuovo hash.
Come accennato in precedenza, il nuovo Hash supportato sarà SHA-256 .

Penso che i crittografi celebrerebbero.

Citazione dall'articolo di Wikipedia su SHA-1 :

Nel febbraio 2005 è stato annunciato un attacco di Xiaoyun Wang, Yiqun Lisa Yin e Hongbo Yu. Gli attacchi possono trovare collisioni nella versione completa di SHA-1, che richiede meno di 2 ^ 69 operazioni. (Una ricerca di forza bruta richiederebbe 2 ^ 80 operazioni.)

Esistono diversi modelli di attacco per hash come SHA-1, ma quello di solito discusso è la ricerca di collisioni, incluso lo strumento HashClash di Marc Stevens .

"A partire dal 2012, l'attacco più efficace contro SHA-1 è considerato quello di Marc Stevens [34] con un costo stimato di $ 2,77 milioni per rompere un singolo valore di hash noleggiando la potenza della CPU dai server cloud."

Come ha sottolineato la gente, potresti forzare una collisione di hash con git, ma farlo non sovrascriverà gli oggetti esistenti in un altro repository. Immagino anche git push -f --no-thinche non sovrascriverà gli oggetti esistenti, ma non sono sicuro al 100%.

Detto questo, se esegui l'hacking in un repository remoto, potresti rendere il tuo oggetto falso il più vecchio lì , possibilmente incorporando il codice hackerato in un progetto open source su github o simile. Se stai attento, forse potresti introdurre una versione compromessa che i nuovi utenti hanno scaricato.

Sospetto tuttavia che molte cose che gli sviluppatori del progetto potrebbero fare potrebbero esporre o distruggere accidentalmente il tuo hack da molti milioni di dollari. In particolare, questo è un sacco di soldi se qualche sviluppatore, che non hai hackerato, esegue mai il suddetto git push --no-thindopo aver modificato i file effettuati, a volte anche senza la --no-thindipendenza.