Haydentherapper

O problema diz respeito à validação insuficiente do “tempo de integração” nos pacotes “v2” e “v3” durante o fluxo de verificação. Isso afeta versões do sigstore-python posteriores à 2.0.0, mas anteriores à 3.6.0. O “tempo de integração” é verificado se houver uma fonte de tempo assinada, como uma promessa de inclusão, mas, caso contrário, é considerado confiável se nenhuma fonte de tempo assinada estiver presente. Isso não afeta os pacotes “v1”, pois eles sempre exigem uma promessa de inclusão. O Sigstore usa a hora assinada para dar suporte à verificação de assinaturas feitas com chaves de assinatura de curta duração. O impacto e a gravidade dessa vulnerabilidade são baixos, pois o Sigstore contém vários outros componentes de imposição que impedem que um invasor se faça passar por uma assinatura válida modificando o carimbo de data/hora de integração. Um invasor que modifique o carimbo de data/hora de integração pode induzir uma negação de serviço, mas isso já é possível com o acesso ao pacote. Um invasor poderia enviar uma nova entrada para o serviço de transparência e substituir a data/hora da nova entrada, mas isso seria rejeitado no momento da validação, pois a data/hora assinada da nova entrada estaria fora da janela de validade do certificado de assinatura original.

O Dex é um serviço de identidade que utiliza o OpenID Connect para facilitar a autenticação em outros aplicativos. Um invasor pode explorar essa vulnerabilidade levando a vítima a acessar um site malicioso e guiando-a pelo fluxo OIDC, roubando o código de autorização OAuth durante o processo. O código de autorização pode então ser trocado por um token, obtendo acesso a aplicativos que aceitem esse token.

Foram identificadas várias falhas no comando `verify-blob` do cosign, nas quais o cosign verificava com sucesso um artefato quando a verificação deveria ter falhado. Essas falhas incluem: - um pacote do cosign pode ser criado para verificar com sucesso um blob mesmo que o rekorBundle incorporado não faça referência à assinatura fornecida, - ao fornecer sinalizadores de identidade, o e-mail e o emissor de um certificado não são verificados ao verificar um pacote Rekor, e a identidade do GitHub Actions nunca é verificada, - fornecer um pacote Rekor inválido sem o sinalizador experimental resulta em uma verificação bem-sucedida, - uma entrada inválida no log de transparência resultará em sucesso imediato na verificação.