flawopen.com/Referenz/Cosign-Verifikations-Bypass

Cosign GHSA-fx35-mq7g-6g98: Verifikations-Bypass bei älteren Bundles

Hoher Schweregrad · CVSS 7,4 CWE-295: Improper Certificate Validation; CWE-347: Improper Verification of Cryptographic Signature Software-Lieferkette

ELI5 — Eintrittskarte und Ausweis

Stellen Sie sich eine Einlasskontrolle vor, die Eintrittskarte und Namen auf einem amtlichen Ausweis prüft. Der verwundbare Pfad für ältere Bundles konnte einen losen Schlüssel mit diesem Ausweis verwechseln und die Karte akzeptieren, ohne den Namen zu prüfen. Die Signatur konnte mathematisch gültig sein, ohne die erforderliche Workflow-Identität nachzuweisen.

Grenze: Verarbeitung älterer JSON-Bundles in den beiden Blob-Verifikationsbefehlen

Fehler: Ein nicht als Zertifikat parsebares `cert`-Feld konnte als öffentlicher Schlüssel behandelt werden; X.509-Kette und Zertifikatsrichtlinie wurden nicht geprüft

Auswirkung: Ein nicht autorisierter Signierer konnte ein bereitgestelltes Blob erfolgreich verifizieren lassen; die Integritätsfolgen hängen von der Weiterverwendung ab

Abhilfe: Auf Cosign v2.6.5 oder v3.1.3 oder neuer aktualisieren und erwartete Zertifikatsidentität sowie OIDC-Issuer pinnen

Was bei der Cosign-Blob-Verifikation fehlschlug

GHSA-fx35-mq7g-6g98 betrifft `cosign verify-blob` und `cosign verify-blob-attestation`, wenn Keyless-Prüfung Identitäts- und Issuer-Flags (oder Regex-Varianten) mit einem älteren JSON-`--bundle` verwendet. War das Feld `cert` kein parsebares X.509-Zertifikat, behandelten betroffene Versionen es als öffentlichen Schlüssel. Dadurch wurde ein interner Signaturprüfer gesetzt und die nachgelagerte Zertifikatskettenprüfung sowie `CheckCertificatePolicy` übersprungen; Identitäts- und Issuer-Vorgaben griffen nicht. Eine für den eingebetteten Schlüssel gültige Signatur konnte erfolgreich sein. Der Bundleschlüssel konnte außerdem ein explizites `--key` überschreiben. Laut Advisory sind Container-Image-Prüfungen und das standardisierte Sigstore-Protobuf-Bundleformat nicht betroffen. Eine CVE ist nicht bekannt; das Upstream-Advisory stuft den Fehler als Hoch, CVSS 7,4, CWE-295 und CWE-347 ein.

Ablauf des Verifikations-Bypasses

Ein CI-Job erhält ein Artefakt und ein älteres JSON-Bundle

Artefakt und Bundle können aus einem Release-Workflow, Cache, Mirror oder einer anderen Pipeline-Eingabe stammen. Der Job muss beide bis zum Abschluss der Richtlinienprüfungen als nicht vertrauenswürdig behandeln.

Der verwundbare Parser akzeptiert einen Schlüssel statt eines Zertifikats

Bei betroffenen Versionen löste ein fehlgeschlagenes X.509-Parsing den Fallback auf einen öffentlichen Schlüssel aus. Dadurch wurde der Signaturprüfer gesetzt und die Zertifikatsrichtlinie der Keyless-Prüfung übersprungen.

Die Signatur besteht, ohne die erwartete Workflow-Identität zu belegen

Die Prüfung kann erfolgreich enden, ohne die festgelegte Zertifikatsidentität und den OIDC-Issuer nachzuweisen. Eine Pipeline, die nur den Rückgabecode prüft, kann dann ein nicht autorisiertes Artefakt übernehmen.

Eine korrigierte Cosign-Version und Signiereridentität festlegen

Das verwundbare Beispiel nutzt breite Regexe und benennt keinen vertrauenswürdigen Workflow. Das korrigierte Beispiel setzt voraus, dass das Artefakt vom angegebenen GitHub-Actions-Workflow signiert wurde; ersetzen Sie die Identität durch die Ihres Release-Workflows. Pinnen Sie Cosign-Binary oder -Image mit geprüfter Version und Digest. Die Befehle verifizieren ein Artefakt; sie erzeugen oder zeigen kein bösartiges Bundle.

CI-Richtlinie — betroffenes VersionsmusterUnbehobener Fehler

# 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$"

CI-Richtlinie — korrigierte VersionBEHOBEN

# 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"

Korrektur- und Rollout-Checkliste

✓Ermitteln Sie alle CI-Jobs mit `cosign verify-blob` oder `cosign verify-blob-attestation` und prüfen Sie die tatsächlich ausgeführte Version, auch heruntergeladene und containerisierte Tools.
✓Aktualisieren Sie betroffene v2-Installationen auf v2.6.5+ und v3-Installationen auf v3.1.3+; bevorzugen Sie eine unterstützte Version und pinnen Sie Herkunft und Digest.
✓Setzen Sie `--certificate-identity` und `--certificate-oidc-issuer` exakt auf den erwarteten Signier-Workflow. Vermeiden Sie `.*`-Regeln, die fremde Identitäten akzeptieren.
✓Migrieren Sie ältere JSON-Bundles nach Möglichkeit zum standardisierten Sigstore-Bundleformat. Laut Advisory ist dessen Prüfpfad nicht betroffen; validieren Sie das genaue Verhalten von Tool und Version beim Rollout.
✓Koppeln Sie Artefakt- und Bundle-Provenienz, brechen Sie bei jedem Verifikationsfehler ab und machen Sie die Veröffentlichung von erfolgreicher Prüfung im selben kontrollierten Job abhängig.
✓Prüfen Sie, ob mit betroffenen Versionen geprüfte Artefakte später veröffentlicht oder ausgerollt wurden. Verifizieren Sie gespeicherte Artefakte mit einer korrigierten Version und der vorgesehenen Identitätsrichtlinie erneut; untersuchen Sie Provenienzabweichungen.

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

Siehe auch Dependency Confusion: Risiken und Schutzmaßnahmen Docker-Socket-Offenlegung: Risiken und Schutz GitHub Actions Script-Injection: Eingaben sicher verarbeiten