Haydentherapper

**Nome do software vulnerável e versões afetadas** sigstore-python, versões 2.0.0 a 3.6.0 **Descrição** 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. **Recomendações** Para as versões 2.0.0 a 3.6.0, atualize para a versão 3.6.0 ou posterior para resolver o problema. Como solução alternativa temporária, considere restringir o acesso ao fluxo de verificação para minimizar o risco de exploração.

**Nome do software vulnerável e versões afetadas** Versões do Dex anteriores à 2.35.0 **Descrição** 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. **Recomendações** Para versões anteriores à 2.35.0, atualize para a versão 2.35.0 para resolver a vulnerabilidade. Como solução alternativa temporária, considere desativar clientes públicos para minimizar o risco de exploração. Observe que a desativação de clientes públicos pode afetar o comportamento do sistema. Não há soluções alternativas conhecidas para versões existentes que não afetem o comportamento do sistema.

**Nome do software vulnerável e versões afetadas** Versões do cosign anteriores à 1.12.0 **Descrição** 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. **Recomendações** Para versões anteriores à 1.12.0, atualize para a versão 1.12.0 para resolver os problemas. Como solução alternativa temporária para o primeiro problema, considere extrair a assinatura e o certificado do pacote e usá-los para verificação em vez do pacote, executando `cosign verify-blob blob1 --signature $(jq -r ‘.base64Signature’ bundle1) --certificate $(jq -r ‘.cert’ bundle1)`. No entanto, observe que essa solução alternativa pode fazer uma chamada de rede para o Rekor e pode estar sujeita ao quarto problema. Para os outros problemas, não há soluções alternativas, e os usuários devem atualizar para a versão 1.12.0.