Git Hash Chain Malleability

Resumen Técnico: Maleabilidad de la Cadena de Hashes de Git

Planteamiento del Problema
El artículo desafía el invariante ampliamente aceptado en los ecosistemas de Git de que un hash de commit identifica de forma única e inmutable una pieza específica de contenido firmado. Mientras que la documentación de Git afirma que los hashes criptográficamente seguros permiten a terceros confiar en el hash como una dirección para el objeto firmado y sus referencias, este documento demuestra que dicha suposición falla para los commits firmados. Específicamente, un atacante sin acceso a la clave de firma privada, y sin romper la función de hash subyacente (SHA-1 o SHA-256), puede generar un objeto de commit distinto con un árbol, metadatos y mensaje idénticos, pero con un hash de commit diferente. Crucialmente, este commit modificado conserva una firma válida y recibe una insignia de "Verificado" de forjas de Git como GitHub. Debido a que el hash del commit es una función determinista de la serialización del contenido (incluyendo los bytes de la firma), alterar los bytes de la firma cambia el hash. Este fenómeno, denominado "maleabilidad de la cadena de hashes", permite a un atacante crear un commit "fantasma" que es funcionalmente idéntico al original pero posee un identificador distinto, provocando cambios en cascada en todos los hashes de commit dependientes de la cadena.

Metodología
El autor identifica que la brecha entre "una firma válida" y "este encoding de firma específico" permite la maleación. Categoriza tres técnicas distintas para explotar esta brecha, cada una dirigida a una capa diferente de la representación de la firma dentro del objeto de commit de Git:

1. Maleación Matemática (ECDSA): Explotando la simetría algebraica de las firmas ECDSA. Para una firma $(r, s)$ en una curva de orden $n$, el par $(r, n-s)$ también es una firma válida para el mismo mensaje. El autor modifica el valor $s$ en el paquete OpenPGP, vuelve a codificar el entero y actualiza los encabezados de longitud del paquete. Esto preserva la validez de la firma mientras altera la secuencia de bytes.
2. Maleación Estructural (RSA y EdDSA): Dirigida a la estructura del contenedor OpenPGP en lugar del valor de la firma en sí. El autor añade un subpaquete bien formado y no crítico (tipo 100, privado/experimental) a la región no hasheada del paquete de la firma. Según el RFC 4880, la región no hasheada no está cubierta por la firma criptográfica. Al añadir datos aquí y ajustar la longitud del paquete, la firma permanece válida, pero la representación de bytes del objeto de commit cambia.
3. Maleación de Codificación (S/MIME): Explotando la diferencia entre DER (Distinguished Encoding Rules) y BER (Basic Encoding Rules) en ASN.1. Las firmas S/MIME son estructuras CMS que requieren una codificación DER canónica. El autor reescribe un campo de longitud dentro del envoltorio CMS de su forma corta canónica a una forma larga equivalente y no canónica (por ejemplo, codificar la longitud 32 como 0x81 0x20 en lugar de 0x20). Aunque esto viola las reglas estrictas de DER, sigue siendo un BER válido. El valor de la firma y el contenido firmado permanecen intactos, preservando la verificación.

Contribuciones Clave

• Caracterización de Técnicas: El documento define y demuestra tres rutas de maleación (matemática, estructural y de codificación) que cubren todos los esquemas de firma soportados por la verificación GPG de GitHub (ECDSA, RSA, EdDSA y S/MIME/CMS).
• Validación en el Lado del Servidor: El autor muestra que estos no son meramente errores de parsing locales. El verificador del lado del servidor de GitHub acepta las tres técnicas de maleación. En consecuencia, la forja emite registros "Verificados" independientes y persistentes tanto para el commit original como para el commit maleado, indexados por sus distintos hashes.
• Análisis de Impacto: El documento analiza las consecuencias para los sistemas que dependen de los hashes de commit como claves primarias direccionables por contenido, incluyendo:
  • Bloqueo basado en Hash: Las herramientas de respuesta ante incidentes que bloquean hashes de commit específicos pueden ser eludidas mediante el envío (push) del commit maleado "fantasma", el cual tiene un hash diferente pero un contenido idéntico.
  • Anclaje de Dependencias (Dependency Pinning): Aunque el anclaje de SHA completo (por ejemplo, en Go modules o Nixpkgs) mantiene la integridad contra la sustitución de contenido, la maleabilidad crea un aliasing al nivel del contenido firmado. Los archivos de bloqueo (lockfiles) regenerados desde espejos pueden registrar el hash "fantasma", lo que genera entradas de caché duplicadas o registros de procedencia inconsistentes.
  • Construcciones Reproducibles (Reproducible Builds): Los sistemas que tratan el hash del commit como el identificador de revisión inmutable (por ejemplo, SLSA Source Track, Sigstore Gitsign) se ven debilitados. Un solo fragmento de contenido puede generar múltiples anclajes "Verificados" en los registros de transparencia, duplicando en lugar de defender el ancla de confianza.
• Herramientas de Prueba de Concepto: El autor proporciona herramientas de código abierto (interactive-malleator.py y setup-ghost.py) que automatizan estas técnicas, reescriben las cadenas de commits descendientes para mantener la consistencia del grafo y verifican los resultados contra forjas locales y remotas.

Resultos

• Verificación Local: Las tres técnicas pasan la verificación local usando git verify-commit para los esquemas basados en OpenPGP (ECDSA, RSA, EdDSA). Para S/MIME, los parsers locales estrictos (como gpgsm usando libksya) rechazan la codificación DER no canónica, pero el parser más permisivo de GitHub la acepta.
• Aceptación de GitHub: GitHub acepta los tres métodos de maleación. La plataforma no canonicaliza los contenedores de firma antes de la verificación. Como resultado, un único commit lógico puede representarse mediante una familia ilimitada de hashes con bytes distintos, cada uno marcado como "Verificado" y presentado como historial independiente en las vistas de comparación (por ejemplo, "1 commit adelante y 1 commit atrás").
• Persistencia: El estatus de "Verificado" es duradero. Incluso si la clave de firma es rotada o revocada, los commits maleados conservan sus registros de verificación independientes porque la forja indexa el registro al hash de commit específico, no al contenido o al estado de la clave.

Significancia
El documento concluye que la suposición de que un hash de commit firmado y verificado es un manejador único para una pieza específica de contenido es falsa. El ataque no depende de colisiones de hash o de la falsificación de contenido, sino de la maleabilidad de la codificación de la firma misma. La significancia práctica es que los sistemas que dependen de los hashes de commit para el bloqueo, el anclaje de dependencias y la verificación de construcciones reproducibles son vulnerables a la equivocación. El autor argumenta que no se debe depositar la confianza en el hash bruto de un objeto firmado cuya codificación es controlada por un adversario; en su lugar, los sistemas deben canonicalizar y verificar el contenido antes de tratar el hash como un identificador único. El documento señala que, a la fecha de su redacción, el problema permanece sin resolver por Git o las principales forjas de Git.