qué - sha-1 git que es
¿Cómo afecta la nueva colisión SHA-1 a Git? (2)
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 repositorio 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 <file>..." to unstage)
new file: shattered-1.pdf
new file: shattered-2.pdf
Aunque los dos archivos tienen la misma suma 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 sumas 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 suma de comprobación antes , hace que ahora produzcan sumas de comprobación diferentes .
La razón por la que esto no debería ser sorprendente es que si el resultado final de la suma 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 suma 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 sumas, 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 stochastic ). A continuación, se les ocurrían dos archivos diferentes que podían eliminar el encabezado blob . Estos dos archivos ahora tendrían diferentes sumas de comprobación SHA-1 entre sí, pero cuando git add -ed, ambos producirían la misma suma de comprobación SHA-1.
En ese caso particular, el primer archivo agregado "ganaría" la ranura. (Asumamos 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 repositorio.
Pero primero, alguien tiene que gastar mucho más tiempo y dinero para calcular la nueva colisión hash.
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?
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 repositorio 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 codificación 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