flawopen.com/संदर्भ/Cosign सत्यापन बाईपास

Cosign GHSA-fx35-mq7g-6g98: पुराने Bundle की जाँच को दरकिनार करना

उच्च गंभीरता · CVSS 7.4 CWE-295: Improper Certificate Validation; CWE-347: Improper Verification of Cryptographic Signature सॉफ़्टवेयर सप्लाई चेन

सरल व्याख्या — टिकट और पहचान-जाँच

ऐसे प्रवेश-द्वार की कल्पना करें जहाँ टिकट के साथ सरकारी पहचान-पत्र पर नाम भी जाँचा जाता है। पुराने Bundle का कमजोर रास्ता एक साधारण कुंजी को पहचान-पत्र समझ सकता था और नाम जाँचे बिना टिकट स्वीकार कर सकता था। हस्ताक्षर गणितीय रूप से सही हो सकता था, पर आवश्यक workflow पहचान साबित नहीं हुई थी।

सीमा: दोनों Blob सत्यापन कमांड में पुराने JSON Bundle को पार्स करना

विफलता: प्रमाणपत्र के रूप में parse न होने वाला `cert` मान सार्वजनिक कुंजी माना जा सकता था, जिससे X.509 chain और प्रमाणपत्र नीति की जाँच छूट जाती थी

प्रभाव: अनधिकृत हस्ताक्षरकर्ता दिए गए Blob का सत्यापन सफल करा सकता था; अखंडता पर प्रभाव उसके आगे के उपयोग पर निर्भर है

उपाय: Cosign को v2.6.5 या v3.1.3 अथवा नए संस्करण पर अपडेट करें और अपेक्षित certificate identity तथा OIDC issuer तय करें

Cosign Blob सत्यापन में क्या विफल हुआ

GHSA-fx35-mq7g-6g98 उन `cosign verify-blob` और `cosign verify-blob-attestation` कमांड को प्रभावित करता है जो पुराने JSON `--bundle` के साथ identity और issuer फ़्लैग (या उनके regex रूप) का उपयोग करके keyless सत्यापन करते हैं। यदि Bundle का `cert` फ़ील्ड X.509 प्रमाणपत्र के रूप में parse नहीं होता, तो प्रभावित संस्करण उसे सार्वजनिक कुंजी के रूप में लोड करते थे। इससे आंतरिक signature verifier सेट हो जाता और आगे की प्रक्रिया certificate-chain जाँच तथा `CheckCertificatePolicy` छोड़ देती; इसलिए identity और issuer की शर्तें लागू नहीं होतीं। embedded कुंजी के लिए हस्ताक्षर सही होने पर सत्यापन सफल हो सकता था। Bundle की कुंजी स्पष्ट रूप से दिए गए `--key` को भी बदल सकती थी। सलाह के अनुसार container image सत्यापन और मानकीकृत Sigstore protobuf Bundle का रास्ता प्रभावित नहीं है। कोई ज्ञात CVE नहीं है; upstream सलाह इसे High, CVSS 7.4, CWE-295 और CWE-347 बताती है।

सत्यापन बाईपास का क्रम

CI जॉब को artifact और पुराना JSON Bundle मिलता है

Artifact और Bundle release workflow, cache, mirror या pipeline के अन्य इनपुट से आ सकते हैं। नीति जाँच पूरी होने तक जॉब को दोनों को अविश्वसनीय मानना चाहिए।

कमजोर parser प्रमाणपत्र की जगह कुंजी स्वीकार करता है

प्रभावित संस्करणों में X.509 parse विफल होने पर सार्वजनिक कुंजी वाला fallback चलता था। इससे signature verifier सेट होता और keyless सत्यापन में प्रमाणपत्र नीति छूट जाती।

ज़रूरी workflow पहचान सिद्ध किए बिना हस्ताक्षर जाँच सफल होती है

तय certificate identity और OIDC issuer स्थापित किए बिना सत्यापन सफल हो सकता है। केवल exit code देखने वाली pipeline अनधिकृत artifact इस्तेमाल कर सकती है।

सुधारा हुआ Cosign संस्करण और हस्ताक्षरकर्ता पहचान तय करें

दोनों उदाहरणों में समान सटीक GitHub Actions पहचान और OIDC issuer तय हैं। कमजोर कमांड Cosign के प्रभावित संस्करण का उपयोग करता है; पुराने JSON Bundle के साथ parser इन जाँचों को दरकिनार कर सकता था। सुरक्षित कमांड सुधारे गए संस्करण और regex के बजाय सटीक मान वाले विकल्पों का उपयोग करता है। CI में जाँचे गए संस्करण और digest से Cosign तय करें। ये कमांड artifact सत्यापित करते हैं; दुर्भावनापूर्ण Bundle नहीं बनाते या दिखाते।

CI नीति — प्रभावित संस्करण का नमूनाअसुधारी गई त्रुटि

# 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 नीति — सुधारा हुआ संस्करणसुधारा गया

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

सुधार और rollout की जाँच-सूची

✓उन CI जॉब की सूची बनाएँ जो `cosign verify-blob` या `cosign verify-blob-attestation` चलाते हैं; डाउनलोड किए गए और container में मौजूद टूल समेत वास्तविक संस्करण जाँचें।
✓प्रभावित v2 इंस्टॉलेशन को v2.6.5+ और v3 को v3.1.3+ पर अपडेट करें; समर्थित संस्करण चुनें और उसकी provenance तथा digest तय करें।
✓अपेक्षित हस्ताक्षर workflow के लिए सटीक `--certificate-identity` और `--certificate-oidc-issuer` सेट करें। असंबंधित पहचान स्वीकार करने वाली `.*` नीति से बचें।
✓जहाँ संभव हो पुराने JSON Bundle को मानकीकृत Sigstore Bundle फ़ॉर्मैट में बदलें। सलाह के अनुसार उसका सत्यापन पथ प्रभावित नहीं है; rollout में टूल और संस्करण का सटीक व्यवहार जाँचें।
✓Artifact और Bundle की provenance को साथ बाँधें, किसी भी सत्यापन त्रुटि पर प्रक्रिया रोकें, और उसी नियंत्रित जॉब में सफल सत्यापन के बाद ही प्रकाशन करें।
✓जाँचें कि प्रभावित संस्करण से सत्यापित artifact बाद में प्रकाशित या deploy तो नहीं हुआ। रखे गए artifact को सुधरे Cosign और अपेक्षित पहचान नीति से दोबारा जाँचें; provenance में अंतर की पड़ताल करें।

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

यह भी देखें Dependency Confusion: जोखिम और बचाव Docker सॉकेट का खुलासा: जोखिम और बचाव GitHub Actions स्क्रिप्ट इंजेक्शन: सुरक्षित इनपुट