¿Cómo manejaría Git una colisión SHA-1 en una gota?

Esto probablemente nunca sucedió en el mundo real todavía, y puede que nunca suceda, pero consideremos esto: digamos que tiene un repositorio git, realice una confirmación y tenga mucha mala suerte: uno de los blobs termina teniendo el mismo SHA-1 como otro que ya está en su repositorio. La pregunta es, ¿cómo manejaría Git esto? ¿Simplemente fallar? ¿Encontrar una manera de vincular los dos blobs y verificar cuál se necesita según el contexto?

Es más un desafío para la mente que un problema real, pero el problema me pareció interesante.

Hice un experimento para descubrir exactamente cómo se comportaría Git en este caso. Esto es con la versión 2.7.9 ~ rc0 + next.20151210 (versión Debian). Básicamente, reduje el tamaño del hash de 160 bits a 4 bits aplicando el siguiente diff y reconstruyendo 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);
 }

Luego hice algunas confirmaciones y noté lo siguiente.

1. Si ya existe un blob con el mismo hash, no recibirá ninguna advertencia en absoluto. Todo parece estar bien, pero cuando empujas, alguien clona o reviertes, perderás la última versión (en línea con lo explicado anteriormente).
2. Si ya existe un objeto de árbol y crea un blob con el mismo hash: Todo parecerá normal, hasta que intente empujar o alguien clone su repositorio. Entonces verás que el repositorio está corrupto.
3. Si ya existe un objeto de confirmación y crea un blob con el mismo hash: igual que # 2 - corrupto
4. Si ya existe un blob y realiza un objeto de confirmación con el mismo hash, fallará al actualizar el "ref".
5. Si ya existe un blob y crea un objeto de árbol con el mismo hash. Fallará al crear el commit.
6. Si ya existe un objeto de árbol y usted hace un objeto de confirmación con el mismo hash, fallará al actualizar la "referencia".
7. Si ya existe un objeto de árbol y usted hace un objeto de árbol con el mismo hash, todo parecerá correcto. Pero cuando se compromete, todo el repositorio hará referencia al árbol incorrecto.
8. Si ya existe un objeto de confirmación y crea un objeto de confirmación con el mismo hash, todo parecerá correcto. Pero cuando confirma, la confirmación nunca se creará y el puntero HEAD se moverá a una confirmación anterior.
9. Si ya existe un objeto de confirmación y crea un objeto de árbol con el mismo hash, fallará al crear la confirmación.

Para el n. ° 2, normalmente obtendrá un error como este cuando ejecute "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)

si elimina el archivo y luego ejecuta "git checkout file.txt".

Para # 4 y # 6, generalmente obtendrá un error como este:

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

cuando se ejecuta "git commit". En este caso, normalmente puede volver a escribir "git commit", ya que esto creará un nuevo hash (debido a la marca de tiempo modificada)

Para los n. ° 5 y n. ° 9, generalmente obtendrá un error como este:

fatal: 1000000000000000000000000000000000000000 is not a valid 'tree' object

cuando se ejecuta "git commit"

Si alguien intenta clonar su repositorio corrupto, normalmente verá algo como:

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'

Lo que me "preocupa" es que en dos casos (2,3) el repositorio se corrompe sin advertencias, y en 3 casos (1,7,8), todo parece estar bien, pero el contenido del repositorio es diferente de lo que espera ser - estar. La clonación o extracción de personas tendrá un contenido diferente al que usted tiene. Los casos 4,5,6 y 9 están bien, ya que se detendrá con un error. Supongo que sería mejor si fallara con un error al menos en todos los casos.

Respuesta original (2012) (ver shattered.iocolisión SHA1 2017 a continuación)

Esa vieja respuesta (2006) de Linus aún podría ser relevante:

No Si tiene el mismo SHA1, significa que cuando recibamos el objeto del otro extremo, no sobrescribiremos el objeto que ya tenemos.

Entonces, lo que sucede es que si alguna vez vemos una colisión, el objeto "anterior" en cualquier repositorio particular siempre terminará por anularse. Pero tenga en cuenta que "anterior" es obviamente por repositorio, en el sentido de que la red de objetos git genera un DAG que no está completamente ordenado, por lo que los diferentes repositorios estarán de acuerdo sobre lo que es "anterior" en el caso de ascendencia directa, si el el objeto llegó a través de ramas separadas y no directamente relacionadas, obviamente dos repositorios diferentes pueden haber obtenido los dos objetos en un orden diferente.

Sin embargo, la "anulación anterior" es lo que desea desde el punto de vista de la seguridad: recuerde que el modelo git es que debe confiar principalmente en su propio repositorio.
Entonces, si hace un " git pull", los nuevos objetos entrantes son, por definición, menos confiables que los objetos que ya tiene, y como tal sería un error permitir que un nuevo objeto reemplace uno viejo.

Entonces tienes dos casos de colisión:

• del tipo inadvertido , donde de alguna manera eres muy desafortunado, y dos archivos terminan teniendo el mismo SHA1.
  En ese momento, lo que sucede es que cuando confirma ese archivo (o hace un " git-update-index" para moverlo al índice, pero aún no lo ha confirmado), se calculará el SHA1 de los nuevos contenidos, pero dado que coincide con un objeto antiguo, no se creará un nuevo objeto, y el commit-or-index termina apuntando al objeto antiguo .
  No lo notará de inmediato (ya que el índice coincidirá con el objeto antiguo SHA1, y eso significa que algo como " git diff" usará la copia extraída), pero si alguna vez hace una diferencia a nivel de árbol (o hace un clon o tirar o forzar un pago) de repente notarás que ese archivo ha cambiado a algocompletamente diferente de lo que esperabas.
  Por lo tanto, generalmente notarías este tipo de colisión bastante rápido.
  En noticias relacionadas, la pregunta es qué hacer con la colisión inadvertida.
  En primer lugar, permítanme recordarles a las personas que la colisión inadvertida es realmente muy, muy poco probable, por lo que es muy probable que nunca la veamos en la historia completa. del universo.
  Pero si sucede, no es el fin del mundo: lo más probable es que tenga que hacer es cambiar el archivo que colisionó ligeramente y forzar una nueva confirmación con el contenido modificado (agregue un comentario que diga " /* This line added to avoid collision */") y luego enseñe a git sobre la magia SHA1 que se ha demostrado que es peligrosa.
  Entonces, durante un par de millones de años, tal vez tengamos que agregar uno o dos valores SHA1 "envenenados" a git. Es muy poco probable que sea un problema de mantenimiento;)

• El tipo de colisión del atacante porque alguien rompió (o fue forzado) SHA1.
  Este es claramente mucho más probable que el tipo inadvertido, pero por definición siempre es un repositorio "remoto". Si el atacante tuviera acceso al repositorio local, tendría formas mucho más fáciles de fastidiarte.
  Entonces, en este caso, la colisión no es un problema : obtendrá un repositorio "malo" que es diferente de lo que pretendía el atacante, pero dado que nunca usará su objeto en colisión, literalmente no es diferente del atacante simplemente no haber encontrado una colisión en absoluto, pero solo usando el objeto que ya tenía (es decir, es 100% equivalente a la colisión "trivial" del archivo idéntico que genera el mismo SHA1).

La cuestión del uso de SHA-256 se menciona regularmente, pero no se actúa por ahora (2012).
Nota: a partir de 2018 y Git 2.19 , el código se está refactorizando para usar SHA-256.

Nota (Humor): puede forzar una confirmación a un prefijo SHA1 particular , con el proyecto gitbrute de Brad Fitzpatrick ( bradfitz) .

gitbrute brute-force un par de marcas de tiempo de autor + committer de modo que el git commit resultante tenga el prefijo deseado.

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

Daniel Dinnyes señala en los comentarios a 7.1 Git Tools - Revision Selection , que incluye:

Existe una mayor probabilidad de que todos los miembros de su equipo de programación sean atacados y asesinados por lobos en incidentes no relacionados en la misma noche.

Incluso el más reciente (febrero de 2017) shattered.iodemostró la posibilidad de forjar una colisión SHA1:
(vea mucho más en mi respuesta por separado , incluida la publicación de Google+ de Linus Torvalds)

• a / todavía requiere más de 9,223,372,036,854,775,808 cálculos SHA1. Esto tomó la potencia de procesamiento equivalente a 6.500 años de cálculos de CPU única y 110 años de cálculos de GPU única.
• b / forjaría un archivo (con el mismo SHA1), pero con la restricción adicional de su contenido y tamaño produciría el SHA1 idéntico (una colisión en el contenido solo no es suficiente): vea " ¿Cómo se calcula el hash git? ") : un blob SHA1 se calcula en función del contenido y el tamaño .

Consulte " Duración de las funciones hash criptográficas " de Valerie Anita Aurora para obtener más información.
En esa página, ella nota:

Google pasó 6500 años de CPU y 110 años de GPU para convencer a todos de que debemos dejar de usar SHA-1 para aplicaciones críticas de seguridad.
También porque era genial

Vea más en mi respuesta separada a continuación .

De acuerdo con Pro Git :

Si sucede que confirma un objeto que tiene el mismo valor SHA-1 que un objeto anterior en su repositorio, Git verá el objeto anterior que ya está en su base de datos de Git y asumirá que ya está escrito. Si intenta revisar ese objeto nuevamente en algún momento, siempre obtendrá los datos del primer objeto.

Por lo tanto, no fallaría, pero tampoco salvaría su nuevo objeto.
No sé cómo se vería eso en la línea de comando, pero eso ciertamente sería confuso.

Un poco más abajo, esa misma referencia intenta ilustrar la probabilidad de tal colisión:

Aquí hay un ejemplo para darle una idea de lo que se necesitaría para obtener una colisión SHA-1. Si todos los 6.500 millones de humanos en la Tierra estuvieran programando, y cada segundo, cada uno produjera código que fuera equivalente al historial completo del kernel de Linux (1 millón de objetos Git) y lo empujara a un enorme repositorio Git, tomaría 5 años hasta ese repositorio contenía suficientes objetos para tener una probabilidad del 50% de una sola colisión de objetos SHA-1. Existe una mayor probabilidad de que todos los miembros de su equipo de programación sean atacados y asesinados por lobos en incidentes no relacionados en la misma noche.

Para agregar a mi respuesta anterior de 2012 , ahora hay (febrero de 2017, cinco años después), un ejemplo de colisión SHA-1 real con shattered.io , donde puede crear dos archivos PDF en colisión: obtener un SHA- 1 firma digital en el primer archivo PDF que también se puede abusar como una firma válida en el segundo archivo PDF.
Consulte también " A las puertas de la muerte durante años, la función SHA1 ampliamente utilizada ahora está muerta ", y esta ilustración .

Actualización 26 de febrero: Linus confirmó los siguientes puntos en una publicación de Google+ :

(1) Primero, el cielo no se está cayendo. Hay una gran diferencia entre usar un hash criptográfico para cosas como la firma de seguridad y usar uno para generar un "identificador de contenido" para un sistema direccionable por contenido como git.

(2) En segundo lugar, la naturaleza de este ataque SHA1 en particular significa que en realidad es bastante fácil mitigarlo, y ya se han publicado dos conjuntos de parches para esa mitigación.

(3) Y finalmente, en realidad hay una transición razonablemente sencilla a otro hash que no romperá el mundo, o incluso los viejos repositorios de git.

Con respecto a esa transición, vea el Q1 2018 Git 2.16 agregando una estructura que representa el algoritmo hash. La implementación de esa transición ha comenzado.

A partir de Git 2.19 (Q3 2018) , Git eligió SHA-256 como NewHash y está en el proceso de integrarlo al código (lo que significa que SHA1 sigue siendo el predeterminado (Q2 2019, Git 2.21), pero SHA2 será el sucesor)

Respuesta original (25 de febrero) Pero:

• Esto permite forjar un blob, sin embargo, el SHA-1 del árbol seguiría cambiando ya que el tamaño del blob forjado podría no ser el mismo que el original: consulte " ¿Cómo se calcula el hash git? "; un blob SHA1 se calcula en función del contenido y el tamaño .
  Se tiene algún problema para git-svnpesar . O más bien con svn en sí , como se ve aquí .
• Como mencioné en mi respuesta original , el costo de tal intento todavía es prohibitivo por ahora (6.500 años de CPU y 100 años de GPU). Véase también Valerie Anita Aurora en " Vidas de funciones hash criptográficas ".
• Como se comentó anteriormente, no se trata de seguridad o confianza, sino de integridad de datos (desduplicación y detección de errores) que puede ser fácilmente detectada por un git fsck, como lo menciona Linus Torvalds hoy. git fsckadvertiría sobre un mensaje de confirmación con datos opacos ocultos después de un NUL(aunque NULno siempre está presente en un archivo fraudulento ).
  No todo el mundo se enciende transfer.fsck, pero GitHub sí: cualquier impulso sería abortado en el caso de un objeto malformado o un enlace roto. Aunque ... hay una razón por la cual esto no está activado por defecto .
• un archivo pdf puede tener datos binarios arbitrarios que puede cambiar para generar un SHA-1 en colisión, en oposición al código fuente falsificado.
  El problema real en la creación de dos repositorios Git con el mismo hash head commit y diferentes contenidos. E incluso entonces, el ataque sigue siendo complicado .
• Linus agrega :

  El objetivo de un SCM es que no se trata de un evento único, sino de un historial continuo. Eso también significa fundamentalmente que un ataque exitoso debe funcionar con el tiempo y no ser detectable.
  Si puede engañar a un SCM una vez, inserte su código, y se detectará la próxima semana, en realidad no hizo nada útil. Solo te quemaste a ti mismo.

Joey Hess prueba esos pdf en un repositorio de Git y encontró :

Eso incluye dos archivos con el mismo SHA y tamaño, que obtienen diferentes blobs gracias a la forma en que git antepone el encabezado al contenido.

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

Si bien agregar datos idénticos a estos archivos en colisión genera otras colisiones, los datos anteriores no lo hacen.

Entonces, el vector principal de ataque (forjar un commit) sería :

• Generar un objeto de confirmación regular;
• use todo el objeto commit + NUL como el prefijo elegido, y
• use el ataque de colisión de prefijo idéntico para generar los objetos buenos / malos colisionantes.
• ... y esto es inútil porque los objetos de confirmación buenos y malos todavía apuntan al mismo árbol.

Además, ya puede detectar ataques de colisión criptoanalíticos contra SHA-1 presente en cada archivo con cr-marcstevens/sha1collisiondetection

Agregar un cheque similar en Git en sí mismo tendría un costo de cálculo .

Al cambiar el hash, Linux comenta :

El tamaño del hash y la elección del algoritmo hash son cuestiones independientes.
Lo que probablemente haría es cambiar a un hash de 256 bits, usarlo internamente y en la base de datos nativa de git y, de forma predeterminada, solo mostrar el hash como una cadena hexadecimal de 40 caracteres (algo así como cómo abreviamos las cosas en muchas situaciones)
De esa manera, las herramientas alrededor de git ni siquiera ven el cambio a menos que se lo pase en algún " --full-hash" argumento especial (o " --abbrev=64" o lo que sea - el valor predeterminado es que abreviamos a 40).

Aún así, un plan de transición (de SHA1 a otra función hash) aún sería complejo , pero se estudiaría activamente.
Una convert-to-object_idcampaña está en progreso :

Actualización 20 de marzo: GitHub detalla un posible ataque y su protección :

A los nombres SHA-1 se les puede asignar confianza a través de varios mecanismos. Por ejemplo, Git le permite firmar criptográficamente una confirmación o etiqueta. Al hacerlo, solo se firma el objeto commit o tag, que a su vez apunta a otros objetos que contienen los datos reales del archivo utilizando sus nombres SHA-1. Una colisión en esos objetos podría producir una firma que parece válida, pero que apunta a datos diferentes de los que pretendía el firmante. En tal ataque, el firmante solo ve la mitad de la colisión, y la víctima ve la otra mitad.

Proteccion:

El reciente ataque utiliza técnicas especiales para explotar las debilidades en el algoritmo SHA-1 que encuentran una colisión en mucho menos tiempo. Estas técnicas dejan un patrón en los bytes que se puede detectar al calcular el SHA-1 de cualquier mitad de un par colisionante.

GitHub.com ahora realiza esta detección para cada SHA-1 que calcula, y aborta la operación si hay evidencia de que el objeto es la mitad de un par colisionante. Eso evita que los atacantes usen GitHub para convencer a un proyecto de que acepte la mitad "inocente" de su colisión, así como evitar que alojen la mitad maliciosa.

Ver " sha1collisiondetection" por Marc Stevens

Nuevamente, con Q1 2018 Git 2.16 agregando una estructura que representa el algoritmo hash, ha comenzado la implementación de una transición a un nuevo hash.
Como se mencionó anteriormente, el nuevo Hash compatible será SHA-256 .

Creo que los criptógrafos lo celebrarían.

Cita del artículo de Wikipedia sobre SHA-1 :

En febrero de 2005, se anunció un ataque de Xiaoyun Wang, Yiqun Lisa Yin y Hongbo Yu. Los ataques pueden encontrar colisiones en la versión completa de SHA-1, lo que requiere menos de 2 ^ 69 operaciones. (Una búsqueda de fuerza bruta requeriría 2 ^ 80 operaciones).

Hay varios modelos de ataque diferentes para hashes como SHA-1, pero el que generalmente se discute es la búsqueda de colisiones, incluida la herramienta HashClash de Marc Stevens .

"A partir de 2012, el ataque más eficiente contra SHA-1 es considerado por Marc Stevens [34] con un costo estimado de $ 2.77M para romper un valor de hash único al alquilar la potencia de la CPU de los servidores en la nube".

Como la gente señaló, podría forzar una colisión de hash con git, pero hacerlo no sobrescribirá los objetos existentes en otro repositorio. Me imagino que incluso git push -f --no-thinno sobrescribirá los objetos existentes, pero no estoy 100% seguro.

Dicho esto, si piratea un repositorio remoto, entonces podría convertir su objeto falso en el más antiguo allí , posiblemente incrustando código pirateado en un proyecto de código abierto en github o similar. Si fue cuidadoso, entonces podría presentar una versión pirateada que los nuevos usuarios descargaron.

Sin embargo, sospecho que muchas cosas que los desarrolladores del proyecto podrían hacer podrían exponer o destruir accidentalmente su truco multimillonario. En particular, eso es una gran cantidad de dinero por el desagüe si algún desarrollador, a quien no hackeaste, alguna vez ejecuta lo mencionado git push --no-thindespués de modificar los archivos afectados, a veces incluso sin la --no-thindependencia.