Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(deps): update module github.com/sigstore/sigstore-go to v0.6.1 [security] #805

Conversation

renovate-bot
Copy link
Contributor

@renovate-bot renovate-bot commented Sep 5, 2024

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
github.com/sigstore/sigstore-go v0.5.1 -> v0.6.1 age adoption passing confidence

GitHub Vulnerability Alerts

CVE-2024-45395

Impact

sigstore-go is susceptible to a denial of service attack when a verifier is provided a maliciously crafted Sigstore Bundle containing large amounts of verifiable data, in the form of signed transparency log entries, RFC 3161 timestamps, and attestation subjects. The verification of these data structures is computationally expensive. This can be used to consume excessive CPU resources, leading to a denial of service attack. TUF's security model labels this type of vulnerability an "Endless data attack," and can lead to verification failing to complete and disrupting services that rely on sigstore-go for verification.

The vulnerable loops are in the verification functions in the package github.com/sigstore/sigstore-go/pkg/verify. The first is the DSSE envelope verification loop in verifyEnvelopeWithArtifact, which decodes all the digests in an attestation can be found here:

https://github.com/sigstore/sigstore-go/blob/725e508ed4933e6f5b5206e32af4bbe76f587b54/pkg/verify/signature.go#L183-L193

The next loop is in the VerifyArtifactTransparencyLog function, which verifies all the signed entries in a bundle:

https://github.com/sigstore/sigstore-go/blob/725e508ed4933e6f5b5206e32af4bbe76f587b54/pkg/verify/tlog.go#L74-L178

The next loop is the VerifyTimestampAuthority function, which verifies all the RFC 3161 timestamps in a bundle:

https://github.com/sigstore/sigstore-go/blob/725e508ed4933e6f5b5206e32af4bbe76f587b54/pkg/verify/tsa.go#L59-L68

Patches

This vulnerability is addressed with sigstore-go 0.6.1, which adds hard limits to the number of verifiable data structures that can be processed in a bundle. Verification will fail if a bundle has data that exceeds these limits. The limits are:

  • 32 signed transparency log entries
  • 32 RFC 3161 timestamps
  • 1024 attestation subjects
  • 32 digests per attestation subject

These limits are intended to be high enough to accommodate the vast majority of use cases, while preventing the verification of maliciously crafted bundles that contain large amounts of verifiable data.

Workarounds

The best way to mitigate the risk is to upgrade to sigstore-go 0.6.1 or later. Users who are vulnerable but unable to quickly upgrade may consider adding manual bundle validation to enforce limits similar to those in the referenced patch prior to calling sigstore-go's verification functions.


Release Notes

sigstore/sigstore-go (github.com/sigstore/sigstore-go)

v0.6.1

Compare Source

What's Changed

v0.6.1 resolves a security advisory for a denial of service. See GHSA-cq38-jh5f-37mq for more information.

Full Changelog: sigstore/sigstore-go@v0.6.0...v0.6.1

v0.6.0

Compare Source

As folks use sigstore-go in more cases, we continue to make fixes and do some minor API interface changes.

Because we are pre-1.0.0 these were made as breaking changes. After 1.0.0 we will provide deprecation notices and smoother migration paths. There may be more minor interface changes between now and v1.0.0.

Breaking Changes

  • In pkg/bundle/bundle.go
    • ProtobufBundle is now Bundle
    • NewProtobufBundle is now NewBundle
  • In pkg/bundle/signature_content.go
    • Use Statement() type was from github.com/in-toto/in-toto-golang/in_toto now comes from github.com/in-toto/attestation/go/v1

What's Changed

Full Changelog: sigstore/sigstore-go@v0.5.1...v0.6.0


Configuration

📅 Schedule: Branch creation - "before 4am" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

Copy link

forking-renovate bot commented Sep 5, 2024

ℹ Artifact update notice

File name: go.mod

In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

  • 8 additional dependencies were updated

Details:

Package Change
github.com/sigstore/sigstore v1.8.7 -> v1.8.9
github.com/google/go-containerregistry v0.20.0 -> v0.20.2
github.com/docker/cli v24.0.7+incompatible -> v27.1.1+incompatible
golang.org/x/crypto v0.25.0 -> v0.26.0
golang.org/x/net v0.26.0 -> v0.27.0
golang.org/x/sys v0.22.0 -> v0.23.0
golang.org/x/term v0.22.0 -> v0.23.0
golang.org/x/text v0.16.0 -> v0.17.0

@renovate-bot renovate-bot requested a review from a team as a code owner September 5, 2024 02:17
@renovate-bot renovate-bot force-pushed the renovate/go-github.com-sigstore-sigstore-go-vulnerability branch from 35ba5e3 to 0eadd02 Compare September 11, 2024 14:20
@renovate-bot renovate-bot force-pushed the renovate/go-github.com-sigstore-sigstore-go-vulnerability branch 2 times, most recently from f06e410 to dff621d Compare October 10, 2024 17:08
@renovate-bot renovate-bot force-pushed the renovate/go-github.com-sigstore-sigstore-go-vulnerability branch from dff621d to b6eb17d Compare October 10, 2024 17:10
@ramonpetgrave64 ramonpetgrave64 enabled auto-merge (squash) October 10, 2024 19:30
@ramonpetgrave64 ramonpetgrave64 merged commit f42f81f into slsa-framework:main Oct 10, 2024
15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants