Un nuevo estudio ha descubierto que el hash de un compromiso de Git firmado no es el nombre único que muchos en la industria del software asumen. Si tiene una confirmación firmada, alguien sin la clave de firma puede crear una segunda confirmación con los mismos archivos, autor, fecha y firma válida, y GitHub aún la marcará como «verificada».
Todo lo que el revisor verifica coincide. Un hash de una confirmación no lo es. Esto es importante porque muchos sistemas tratan un hash de confirmación verificado como un nombre único persistente para su contenido.
Las fallas específicas son: Bloquear una confirmación incorrecta con un hash permite a un atacante volver a enviar el mismo contenido con un hash nuevo, pero «verificado», que la lista de bloqueo nunca ha visto. La deduplicación, el registro de procedencia y los registros de compilación reproducibles con clave hash heredan el mismo punto débil.
Un espejo comprometido u hostil podría pasar un compromiso firmado válidamente al clonador que difiere del hash de la forja legítima.
Esta no es forma de conseguir que otro fragmento de código pase la verificación de firma. Dado que el archivo es idéntico en todas las copias, el hash anclado obtendrá exactamente lo que espera o fallará.
No hay CVE ni avisos de proveedores, y no necesita cambiar nada en su propio repositorio. El error está en la forma en que Forge determina lo que significa «verificado», y la solución pertenece a Forge.
La investigación es de Jacob Ginesin, estudiante de doctorado de la Universidad Carnegie Mellon y criptoauditor de Cure53. Su artículo de cinco páginas, publicado en arXiv el 2 de julio, incluye herramientas públicas para realizar los tres ataques, así como dos repositorios de demostración donde las confirmaciones atacadas todavía aparecen como «verificadas» en GitHub.
Cada confirmación nombra a su padre con un hash, por lo que procesar una confirmación fuerza un nuevo hash en las confirmaciones superiores. La herramienta reescribe esa cadena para mantenerla consistente. Sin embargo, el descendiente firmado pierde su propia insignia en el momento en que cambia el puntero del padre. Ginesin llama a este efecto «maleabilidad de la cadena hash».
La causa es la maleabilidad característica. El hash de una confirmación se calcula sobre todo lo que contiene la confirmación, incluidos los bytes sin procesar de la firma en el encabezado. Muchas firmas se pueden reescribir en otra forma aún válida, y al cambiar estos bytes se cambia el hash sin tocar una línea de código.
Las tres rutas cubren todos los esquemas GPG y S/MIME que valida GitHub.
Las tres rutas comparten un facilitador. GitHub no canonicaliza las firmas antes de verificarlas. No existe una codificación estricta en S/MIME, ni eliminación de campos OpenPGP, y los valores ECDSA no canónicos se aceptan tal cual.
Luego, GitHub archiva un registro «verificado» para cada hash de confirmación y no vuelve a verificar, por lo que la confirmación permanece «verificada» incluso después de que se revoca la clave de firma. Cuando insertas un original y su gemelo en dos ramas, la vista comparativa de GitHub los trata como historial de ramas, aunque los archivos sean idénticos. Un compromiso está al frente y otro detrás.
Para ser claros, esto no es una colisión de hash. Esto no rompe SHA-1 o SHA-256, y no tiene nada que ver con el cambio de Git a SHA-256. Nadie obliga a dos confirmaciones diferentes a compartir un hash. Es al revés, una confirmación se puede escribir de muchas formas válidas diferentes, cada una con su propio hash.
La solución en este documento rima con normalizar la codificación antes de confiar en el hash. No es un código nuevo y raro, sino una lección conocida.
El documento también vincula esto con el reciente secuestro de etiquetas de GitHub Actions, el ataque tj-actions/changed-files de 2025 y el ataque trivy-action de 2026 (citando este último). El consejo posterior fue simple: atenerse al hash de confirmación completo en lugar de una etiqueta móvil. Ese consejo todavía se aplica.
Pinning detuvo estos ataques y este estudio continúa haciéndolo. Ese punto es aún más limitado. En el caso de Trivy, las confirmaciones maliciosas eran prominentes porque no podían firmarse válidamente. Esta es una advertencia contra apegarse demasiado a esa idea. Una firma válida demuestra quién firmó la confirmación, pero el hash de la confirmación no se convierte en un nombre único para su contenido.
Source link
