¿Cómo afecta la nueva colisión SHA-1 a Git?

Recientemente, un equipo de investigadores generó dos archivos con el mismo hash SHA-1 ( https://shattered.it/ ).

Dado que Git usa este hash para su almacenamiento interno, ¿hasta qué punto este tipo de ataque influye en Git?

Editar, a fines de diciembre de 2017: la versión 2.16 de Git está adquiriendo interfaces internas para permitir diferentes valores hash . Todavía queda un largo camino por recorrer.


La respuesta breve (pero insatisfactoria) es que los archivos de ejemplo no son un problema para Git, pero podrían ser otros dos archivos (cuidadosamente calculados).

Descargué ambos archivos, shattered-1.pdf y shattered-2.pdf , y los puse en un nuevo repository vacío:

 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 

Aunque los dos archivos tienen la misma sum de comprobación SHA-1 (y muestran casi lo mismo, aunque uno tiene un fondo rojo y el otro tiene un fondo azul), obtienen diferentes hash Git :

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

Esas son las dos sums de comprobación SHA-1 para los archivos almacenados en Git : uno es ba9aa... y el otro es b621e... Tampoco lo es 38762c... Pero, ¿por qué?

La respuesta es que Git almacena archivos, no como si fueran ellos mismos, sino como el blob literal de cadena, un espacio en blanco, el tamaño del archivo decimalizado y un byte ASCII NUL, y luego los datos del archivo. Ambos archivos son exactamente del mismo tamaño:

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

por lo que ambos tienen como prefijo el blob 422435\0 texto literal blob 422435\0 (donde \0 representa un solo byte, a la C o python escapes octales en cadenas).

Quizás sorprendentemente, o no, si sabes algo de cómo se calcula SHA-1, agregar el mismo prefijo a dos archivos diferentes que, sin embargo, produjeron la misma sum de comprobación antes , hace que ahora produzcan sums de comprobación diferentes .

La razón por la que esto no debería ser sorprendente es que si el resultado final de la sum de comprobación no fuera exquisitamente sensible a la posición , así como el valor de cada bit de entrada, sería fácil producir colisiones a demanda tomando un archivo de entrada conocido y simplemente re -Arreglo de algunos de sus bits. Estos dos archivos de entrada producen la misma sum a pesar de tener un byte diferente en char 193, line 8 , pero este resultado se logró, según los investigadores, al probar más de 9 quintillones (a pequeña escala ). Para obtener ese resultado, colocaron bloques cuidadosamente seleccionados de datos en bruto, en una posición que controlaban, que afectarían las sums, hasta que encontraron pares de entradas que resultaron en una colisión.

Al agregar el encabezado blob , Git movió la posición , destruyendo los 110 años de computación de la GPU en un solo eructo más o menos accidental.

Ahora, sabiendo que Git hará esto, podrían repetir sus 110 años de computación GPU con entradas que comienzan con blob 422435\0 (a condición de que sus bloques sacrificatorios no sean presionados demasiado y el número real de GPU). años de computación necesarios probablemente variarían, ya que el proceso es un tanto estocástico ). A continuación, se les ocurrían dos archivos diferentes que podían eliminar el encabezado blob . Estos dos archivos ahora tendrían diferentes sums de comprobación SHA-1 entre sí, pero cuando git add -ed, ambos producirían la misma sum de comprobación SHA-1.

En ese caso particular, el primer archivo agregado “ganaría” la ranura. (Asummos que se llama shattered-3.pdf ). Un Git suficientemente bueno. No estoy del todo seguro de que el Git actual sea tan bueno; ver la respuesta basada en experimentos de Ruben a ¿Cómo manejaría Git una colisión SHA-1 en un blob? – notaría que git add shattered-4.pdf , intentando agregar el segundo archivo, colisionó con el primero -pero-diferente shattered-3.pdf y le advertiría y fallaría el paso de git add . En cualquier caso, no podrá agregar ambos archivos a un único repository.

Pero primero, alguien tiene que gastar mucho más tiempo y dinero para calcular la nueva colisión hash.

Tal vez la respuesta de Linus arroje algo de luz:

IIRC alguien ha estado trabajando en la parametrización de las suposiciones SHA1 de git para que un repository eventualmente pueda usar un hash más seguro. ¿Qué tan lejos ha llegado eso? Todavía hay muchas constantes “40” en git.git HEAD.

No creo que necesariamente quieras cambiar el tamaño del hash. Puede usar un hash diferente y simplemente usar los mismos 160 bits de él.

Como ahora tenemos colisiones en archivos PDF válidos, es probable que se puedan construir colisiones en commit de git válidos y objetos de árbol.

Todavía no he visto el ataque, pero git no solo ha copiado los datos, sino que lo antepone a un campo de tipo / longitud. Eso generalmente hace que los ataques de colisión sean mucho más difíciles, porque o bien tienes que hacer que el tamaño resultante sea el mismo, o también debes poder editar el campo de tamaño en el encabezado.

Los pdf no tienen ese problema, tienen un encabezado fijo y usted puede agregar bastante arbitrariamente datos silenciosos al medio que simplemente no se muestran.

Así que los pdf hacen un vector de ataque mucho mejor, exactamente porque son un formato de datos bastante opaco. Git tiene datos opacos en algunos lugares (ocultamos cosas en objetos de compromiso intencionalmente, por ejemplo, pero por definición los datos opacos son bastante secundarios).

Dicho de otra manera: dudo que el cielo se está cayendo por git como una herramienta de gestión de control de origen. ¿Queremos migrar a otro hash? Sí. ¿Se acabó el juego para SHA1 como la gente quiere decir? Probablemente no.

No he visto los detalles del ataque, pero apuesto

(a) el hecho de que tenemos una encoding de tamaño diferente hace que sea mucho más difícil hacerlo en objetos git en primer lugar

(b) probablemente podamos agregar fácilmente algunos controles de cordura adicionales a los datos opacos que tenemos, para que sea mucho más difícil ocultar los datos aleatorios de los que dependen estos ataques.

Linus

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