flawopen.com/Referência/Desvio na verificação do Cosign

Cosign GHSA-fx35-mq7g-6g98: desvio na verificação de bundle legado

Alta severidade · CVSS 7,4 CWE-295: Improper Certificate Validation; CWE-347: Improper Verification of Cryptographic Signature Cadeia de suprimentos de software

ELI5 — O ingresso e a conferência de identidade

Imagine uma casa de shows que confere o ingresso e o nome em um documento oficial. O caminho vulnerável do bundle legado podia confundir uma chave avulsa com esse documento e aceitar o ingresso sem conferir o nome. A assinatura podia ser matematicamente válida, mas a identidade exigida do workflow não havia sido comprovada.

Limite: Limite: leitura de bundles JSON legados em `cosign verify-blob` e `cosign verify-blob-attestation`

Falha: Falha: um valor `cert` que não pudesse ser interpretado como certificado podia ser tratado como chave pública, contornando a validação da cadeia X.509 e da política do certificado

Impacto: Impacto: um assinante não autorizado podia obter uma verificação bem-sucedida para um blob fornecido; o impacto na integridade depende do uso posterior

Correção: Correção: atualizar para Cosign v2.6.5 ou v3.1.3, ou posterior, e fixar a identidade esperada do certificado e o emissor OIDC

O fallback de leitura que atravessava o limite de confiança

GHSA-fx35-mq7g-6g98 afeta `cosign verify-blob` e `cosign verify-blob-attestation` quando a verificação sem chave usa flags de identidade e emissor (ou suas variantes com regex) junto de `--bundle` JSON legado. Se o campo `cert` do bundle não fosse interpretado como certificado X.509, as versões afetadas tentavam carregá-lo como chave pública. Isso definia um verificador interno de assinatura e fazia o fluxo seguinte ignorar a validação da cadeia do certificado e `CheckCertificatePolicy`; portanto, as restrições de identidade e emissor não eram aplicadas. Uma assinatura válida para a chave embutida podia retornar sucesso. A chave do bundle também podia substituir uma `--key` fornecida explicitamente. O aviso informa que a verificação de imagens de contêiner e o formato padronizado de bundle protobuf do Sigstore não são afetados. Não há CVE conhecido; o aviso upstream classifica o problema como Alto, CVSS 7,4, CWE-295 e CWE-347.

Como a falha de verificação chegava à decisão de publicar

Um job de CI recebe um artefato e um bundle JSON legado

O artefato e o bundle podem vir de um workflow de release, cache, espelho ou outra entrada do pipeline; o job deve tratar ambos como não confiáveis até concluir as verificações de política.

O parser vulnerável aceita uma chave onde esperava um certificado

Nas versões afetadas, uma falha ao interpretar X.509 acionava o fallback para chave pública. Isso preenchia o verificador de assinatura e ignorava a política de certificado da verificação sem chave.

A assinatura passa sem comprovar a identidade exigida do workflow

A verificação pode terminar com sucesso sem estabelecer a identidade do certificado e o emissor OIDC fixados. Um pipeline que só testa o código de saída pode então consumir um artefato não autorizado.

Fixe uma versão corrigida do Cosign e a identidade do assinante

Os dois exemplos fixam a mesma identidade exata do GitHub Actions e o mesmo emissor OIDC. O comando vulnerável usa uma versão afetada do Cosign; com um bundle JSON legado, o parser ainda podia contornar essas verificações. O comando reforçado usa uma versão corrigida e flags de valor exato em vez de expressões regulares. Fixe no CI o binário ou contêiner do Cosign por uma versão e um digest revisados. Os comandos verificam um artefato; não criam nem demonstram um bundle malicioso.

Política de CI — versão afetadaFALHA NÃO CORRIGIDA

# Risco: versões afetadas aceitam bundles JSON legados neste fluxo
# cosign v2.6.4 ou anterior, ou v3.1.2 ou 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 — versão corrigidaCORREÇÃO REFORÇADA

# Exija Cosign v2.6.5+ ou v3.1.3+ na cadeia de ferramentas do 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 correção e implantação

✓Faça o inventário dos jobs de CI que executam `cosign verify-blob` ou `cosign verify-blob-attestation`; confira a versão realmente executada, inclusive ferramentas baixadas ou dentro de contêineres.
✓Atualize instalações afetadas da série v2 para v2.6.5+ e da série v3 para v3.1.3+; prefira uma versão atualmente suportada e fixe sua procedência e seu digest.
✓Defina `--certificate-identity` e `--certificate-oidc-issuer` exatos para o workflow de assinatura esperado. Evite políticas `.*` que aceitam identidades não relacionadas.
✓Quando viável, migre bundles JSON legados para o formato padronizado de bundle Sigstore. O aviso identifica o fluxo de verificação desse formato como não afetado; valide o comportamento exato da ferramenta e da versão durante a implantação.
✓Mantenha a procedência do artefato vinculada à do bundle, falhe de modo fechado diante de qualquer erro de verificação e condicione a publicação à verificação bem-sucedida no mesmo job controlado.
✓Verifique se artefatos validados por versões afetadas foram publicados ou implantados depois. Revalide os artefatos retidos com uma versão corrigida do Cosign e a política de identidade prevista; investigue divergências de procedência.

Explore análises relacionadas a vulnerabilidades e cadeia de suprimentos:Diretório de segurança →

Veja também Dependency Confusion: riscos e defesas Exposição do Socket Docker: riscos e defesas Injeção de scripts no GitHub Actions: entradas seguras