flawopen.com/Referencia/Evasión de verificación de Cosign

Cosign GHSA-fx35-mq7g-6g98: evasión al verificar bundles antiguos

Gravedad alta · CVSS 7,4 CWE-295: Improper Certificate Validation; CWE-347: Improper Verification of Cryptographic Signature Cadena de suministro de software

ELI5 — La entrada y la identificación

Imagina que un local comprueba tanto la entrada como el nombre en un documento oficial. La ruta vulnerable del bundle antiguo podía confundir una clave suelta con ese documento y aceptar la entrada sin comprobar el nombre. La firma podía ser matemáticamente válida, pero no se había demostrado la identidad requerida del workflow.

Límite: Límite: análisis de bundles JSON antiguos en `cosign verify-blob` y `cosign verify-blob-attestation`

Fallo: Fallo: un valor `cert` que no se pudiera analizar como certificado podía tratarse como clave pública sin validar la cadena X.509 ni la política del certificado

Impacto: Impacto: un firmante no autorizado podía obtener una verificación correcta para un blob suministrado; el impacto sobre la integridad depende del uso posterior

Corrección: Corrección: actualizar a Cosign v2.6.5 o v3.1.3, o posterior, y fijar la identidad del certificado y el emisor OIDC esperados

El fallback de análisis que cruzó el límite de confianza

GHSA-fx35-mq7g-6g98 afecta a `cosign verify-blob` y `cosign verify-blob-attestation` cuando la verificación sin clave usa las opciones de identidad y emisor (o sus variantes regex) con un `--bundle` JSON antiguo. Si el campo `cert` del bundle no se podía analizar como certificado X.509, las versiones afectadas intentaban cargarlo como clave pública. Esto establecía un verificador interno de firmas y hacía que la ruta posterior omitiera la validación de la cadena del certificado y `CheckCertificatePolicy`; por tanto, no se aplicaban las restricciones de identidad y emisor. Una firma válida para esa clave incrustada podía devolver éxito. La clave del bundle también podía sustituir a una `--key` indicada explícitamente. El aviso indica que la verificación de imágenes de contenedor y la ruta del formato estandarizado de bundle protobuf de Sigstore no están afectadas. No hay un CVE conocido; el aviso upstream lo clasifica como Alto, CVSS 7,4, CWE-295 y CWE-347.

Cómo el fallo de verificación llegaba a la decisión de publicar

Un job de CI recibe un artefacto y un bundle JSON antiguo

El artefacto y el bundle pueden proceder de un workflow de release, una caché, un mirror u otra entrada del pipeline; el job debe considerar ambos no confiables hasta que se apliquen las políticas.

El parser vulnerable acepta una clave donde esperaba un certificado

En las versiones afectadas, un error al analizar X.509 activaba el fallback a clave pública. Esto establecía el verificador de firmas y omitía la aplicación de políticas de certificados en la verificación sin clave.

La firma se valida sin demostrar la identidad requerida del workflow

La verificación puede finalizar correctamente sin establecer la identidad del certificado ni el emisor OIDC fijados. Un pipeline que solo comprueba el código de salida puede consumir un artefacto no autorizado.

Fija una versión corregida de Cosign y la identidad del firmante

Ambos ejemplos fijan la misma identidad exacta de GitHub Actions y el mismo emisor OIDC. El comando vulnerable usa una versión afectada de Cosign; con un bundle JSON antiguo, su parser aún podía eludir esas comprobaciones. El comando reforzado usa una versión corregida y opciones de valor exacto en vez de expresiones regulares. Fija el binario o contenedor de Cosign por una versión y un digest revisados. Los comandos verifican un artefacto; no crean ni muestran un bundle malicioso.

Política de CI — versión afectadaFALLO SIN CORREGIR

# Riesgo: las versiones afectadas aceptan bundles JSON antiguos aquí
# cosign v2.6.4 o anterior, o v3.1.2 o anterior
cosign verify-blob release.tar.gz \
  --bundle release.sigstore.json \
  --certificate-identity-regexp "^https://github\.com/acme/service/\.github/workflows/release\.yml@refs/heads/main$" \
  --certificate-oidc-issuer-regexp "^https://token\.actions\.githubusercontent\.com$"

Política de CI — versión corregidaCORRECCIÓN REFORZADA

# Exige Cosign v2.6.5+ o v3.1.3+ en la cadena de herramientas de CI
cosign verify-blob release.tar.gz \
  --bundle release.sigstore.json \
  --certificate-identity "https://github.com/acme/service/.github/workflows/release.yml@refs/heads/main" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com"

Lista de corrección y despliegue

✓Inventaría los jobs de CI que ejecutan `cosign verify-blob` o `cosign verify-blob-attestation`; comprueba la versión realmente ejecutada, incluidas las herramientas descargadas o incluidas en contenedores.
✓Actualiza instalaciones afectadas de v2 a v2.6.5+ y de v3 a v3.1.3+; prefiere una versión con soporte vigente y fija su procedencia y digest.
✓Configura `--certificate-identity` y `--certificate-oidc-issuer` exactos para el workflow de firma esperado. Evita políticas `.*` que acepten identidades ajenas.
✓Migra los bundles JSON antiguos al formato estandarizado de bundle Sigstore cuando sea viable. El aviso señala que la ruta de verificación de ese formato no está afectada; valida el comportamiento exacto de la herramienta y su versión durante el despliegue.
✓Mantén vinculada la procedencia del artefacto y del bundle, falla de forma segura ante cualquier error de verificación y condiciona la publicación a una verificación correcta en el mismo job controlado.
✓Comprueba si después se publicaron o desplegaron artefactos verificados con versiones afectadas. Vuelve a verificar los artefactos conservados con una versión corregida de Cosign y la política de identidad prevista; investiga discrepancias de procedencia.

Consulta análisis relacionados sobre vulnerabilidades y cadena de suministro:Directorio de seguridad →

Véase también Dependency Confusion: riesgos y defensas Exposición del socket de Docker: riesgos y defensas Inyección de scripts en GitHub Actions: entradas seguras