flawopen.com/Référence/Contournement de vérification Cosign

Cosign GHSA-fx35-mq7g-6g98 : contournement de vérification des bundles hérités

Gravité élevée · CVSS 7,4 CWE-295: Improper Certificate Validation; CWE-347: Improper Verification of Cryptographic Signature Chaîne d’approvisionnement logicielle

ELI5 — Le billet et la pièce d’identité

Imaginez un contrôle qui vérifie un billet et le nom sur une pièce d’identité officielle. Le chemin vulnérable des bundles hérités pouvait prendre une clé isolée pour cette pièce et accepter le billet sans vérifier le nom. La signature pouvait être mathématiquement valide sans prouver l’identité du workflow attendu.

Limite : Analyse des bundles JSON hérités dans les deux commandes de vérification de blobs

Échec : Une valeur `cert` non analysable comme certificat pouvait être traitée comme clé publique, sans valider la chaîne X.509 ni la politique du certificat

Impact : Un signataire non autorisé pouvait faire accepter un blob fourni; l’effet sur l’intégrité dépend de son utilisation ultérieure

Correction : Passer à Cosign v2.6.5 ou v3.1.3 ou ultérieur; épingler l’identité du certificat et l’émetteur OIDC attendus

Ce qui a échoué dans la vérification des blobs Cosign

GHSA-fx35-mq7g-6g98 concerne `cosign verify-blob` et `cosign verify-blob-attestation` lorsque la vérification sans clé utilise les options d’identité et d’émetteur (ou leurs variantes regex) avec un `--bundle` JSON hérité. Si le champ `cert` ne pouvait pas être analysé comme certificat X.509, les versions concernées le chargeaient comme clé publique. Cela activait un vérificateur de signature interne et faisait ignorer la validation de la chaîne et `CheckCertificatePolicy`; les contraintes d’identité et d’émetteur n’étaient donc pas appliquées. Une signature valide pour la clé intégrée pouvait réussir. La clé du bundle pouvait aussi remplacer une option `--key` explicite. L’avis indique que la vérification d’images de conteneur et le format protobuf standardisé de bundle Sigstore ne sont pas concernés. Aucun CVE n’est connu; l’avis classe la faille Élevée, CVSS 7,4, CWE-295 et CWE-347.

Contournement de vérification

Un job CI reçoit un artefact et un bundle JSON hérité

L’artefact et le bundle peuvent provenir d’un workflow de publication, d’un cache, d’un miroir ou d’une autre entrée du pipeline; le job doit les considérer non fiables tant que les contrôles de politique ne sont pas terminés.

Le parseur vulnérable accepte une clé à la place d’un certificat

Dans les versions concernées, l’échec d’analyse X.509 déclenchait un fallback vers une clé publique. Cela activait le vérificateur de signature et contournait les règles de certificat de la vérification sans clé.

La signature réussit sans prouver l’identité attendue du workflow

La vérification peut réussir sans établir l’identité de certificat et l’émetteur OIDC attendus. Un pipeline qui ne contrôle que le code de retour peut alors consommer un artefact non autorisé.

Épingler une version corrigée de Cosign et l’identité du signataire

Les deux exemples épinglent la même identité GitHub Actions exacte et le même émetteur OIDC. La commande vulnérable utilise une version concernée de Cosign; avec un bundle JSON hérité, son parseur pouvait contourner ces contrôles. La commande corrigée utilise une version réparée et des options à valeur exacte plutôt que des expressions régulières. Épinglez le binaire ou conteneur Cosign par version et digest vérifiés. Ces commandes vérifient un artefact; elles ne créent ni ne montrent de bundle malveillant.

Politique CI — modèle de version concernéeDéfaut non corrigé

# Risk: affected versions accept legacy JSON bundles in this path
# cosign v2.6.4 or earlier, or v3.1.2 or earlier
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$"

Politique CI — version corrigéeCORRIGÉ

# Require Cosign v2.6.5+ or v3.1.3+ in the pinned CI toolchain
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"

Mesures de correction et de déploiement

✓Recensez les jobs CI qui exécutent `cosign verify-blob` ou `cosign verify-blob-attestation`; vérifiez la version réellement utilisée, y compris les outils téléchargés ou en conteneur.
✓Mettez à niveau les installations v2 concernées vers v2.6.5+ et les installations v3 vers v3.1.3+; privilégiez une version maintenue et épinglez sa provenance et son digest.
✓Définissez exactement `--certificate-identity` et `--certificate-oidc-issuer` pour le workflow attendu. Évitez les politiques `.*` qui acceptent d’autres identités.
✓Migrez si possible les bundles JSON hérités vers le format de bundle Sigstore standardisé. L’avis indique que son chemin de vérification n’est pas concerné; validez le comportement exact de l’outil et de sa version lors du déploiement.
✓Liez la provenance de l’artefact à celle du bundle, échouez de manière fermée à toute erreur de vérification et conditionnez la publication à une vérification réussie dans le même job contrôlé.
✓Vérifiez si des artefacts contrôlés avec des versions concernées ont ensuite été publiés ou déployés. Recontrôlez les artefacts conservés avec une version corrigée et la politique d’identité prévue; enquêtez sur les écarts de provenance.

Browse related vulnerability and supply-chain analysis:Security directory →

À voir aussi Dependency Confusion : risques et défenses Exposition du socket Docker : risques et défenses Injection de scripts GitHub Actions : entrées sûres