Forjando commits firmados en GitHub

Artículo original ↗ Discusión en Hacker News ↗

El uso por parte de GitHub de un parser basado en regex para los metadatos de los commits permitió un exploit que falsificó commits firmados “verificados por GitHub” al desincronizar la forma en que Git y GitHub interpretaban el campo author. Los comentaristas argumentan que esto ejemplifica los riesgos del análisis ad hoc y de los desajustes entre parsers en código sensible a la seguridad, y muchos piden usar las propias bibliotecas de Git o parsers más estrictos, guiados por especificaciones. El incidente también alimenta un escepticismo más amplio sobre el valor de seguridad de los commits firmados, las firmas gestionadas por GitHub y los procesos de triaje de errores que inicialmente restan importancia a informes de este tipo.

Causa raíz: regex frente a análisis correcto

  • Muchos comentaristas ven esto como un caso de libro de “no analices formatos estructurados con regex ad hoc”, especialmente en código crítico para la seguridad.
  • Otros subrayan que el problema más profundo es un desajuste entre parsers: la lógica de regex personalizada de GitHub y el parser de Git no coinciden en lo que es válido, lo que permite ataques de desincronización.
  • Varios sostienen que la única opción realmente segura es reutilizar la propia implementación de Git (o libgit2), no volver a implementar el análisis en absoluto.
  • Algunos defienden regex si se usan en comprobaciones pequeñas, bien acotadas y de varios pasos (por ejemplo, primero localizar líneas author , luego validar estrictamente el formato y fallar ante cualquier cosa extraña).

Especificación, validación y la ley de Postel

  • Los comentaristas critican la corrección como “simplemente retocar la regex” en lugar de especificar correctamente el formato de la cabecera del commit y aplicarlo con un parser estricto.
  • Patrón más seguro sugerido: fallar rápido ante múltiples líneas author, líneas mal formadas o cualquier cosa inesperada.
  • El principio de robustez de Postel (“ser flexible en lo que aceptas”) es muy criticado por ser incompatible con la seguridad moderna; un análisis permisivo convierte en tu problema las entradas defectuosas de otros.
  • Otros señalan que la ley de Postel ayudó históricamente a la interoperabilidad de Internet temprana, pero ahora es peligrosa para componentes sensibles a la seguridad.

Significado y valor de los commits firmados por GitHub

  • Algunos tratan “firmado por la firma verificada de GitHub” como equivalente a no firmado, ya que no es la clave propia del autor.
  • Otros ven valor: da fe de que el commit llegó a través de la interfaz web de GitHub o Codespaces bajo una cuenta autenticada, y ofrece una marca de tiempo de confianza—útil en algunos escenarios de cadena de suministro y de antedatado, suponiendo que GitHub no esté comprometido.
  • Hay confusión e irritación porque GitHub reescribe el committer para que sea GitHub mismo y así adjuntar la insignia verificada; los críticos ven esto como una contaminación de los metadatos de Git, mientras que los partidarios dicen que encaja con el modelo author/committer (la herramienta o el mantenedor actuando en nombre del autor).
  • Se considera que usar una sola clave de firma para todos los usuarios aumenta el radio de explosión de errores como este.

Commits firmados: utilidad y dolor práctico

  • Algunos consideran que los commits firmados son en gran medida inútiles: si los atacantes pueden enviar código, a menudo también pueden firmarlo.
  • Otros destacan su papel para mitigar riesgos de cadena de suministro, pero solo si la confianza en la clave es significativa (web of trust de PGP, claves servidas por el dominio o claves alojadas por la plataforma).
  • La configuración y las herramientas se ven como engorrosas, aunque se menciona que la firma basada en SSH y las integraciones con gestores de contraseñas facilitan el proceso.
  • Hay acuerdo en que los endpoints de firma ciega (como Codespaces firmando commits arbitrarios) aumentan drásticamente la complejidad y la superficie de ataque.

Proceso de seguridad y transparencia

  • Varios comentarios critican la triaje de vulnerabilidades de GitHub (y de las grandes empresas): mucho ruido procedente de informes de baja calidad lleva a personal junior a cerrar problemas reales como “no es un bug”.
  • Las anécdotas destacan organizaciones que desestiman hallazgos serios como “comportamiento previsto” hasta que intervienen reguladores o la exposición pública.
  • Algunos señalan como preocupante el patrón de GitHub de cerrar rápidamente problemas de seguridad y la falta de un post-mortem público detallado (incluido si el error llegó a explotarse alguna vez).