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

Verify pass private Rekor check even without Rekor public key #1816

Closed
clem844 opened this issue Apr 29, 2022 · 4 comments · Fixed by #1833
Closed

Verify pass private Rekor check even without Rekor public key #1816

clem844 opened this issue Apr 29, 2022 · 4 comments · Fixed by #1833
Assignees
Labels
bug Something isn't working

Comments

@clem844
Copy link

clem844 commented Apr 29, 2022

cosign v1.8.0
I use a private Rekor instance
I did not initialize cosign with my own TUF signed Rekor public key so it is using the public targets from DefaultRemoteRoot = "sigstore-tuf-root"
However, when verifying, cosign does not seem to need the Rekor public key:

COSIGN_EXPERIMENTAL=1 cosign verify --key cosign.pub --rekor-url http://10.20.0.26:3000 my-registry.com/artifacts-signature | jq

Verification for my-registry.com/artifacts-signature:latest --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - The claims were present in the transparency log
  - The signatures were integrated into the transparency log when the certificate was valid
  - The signatures were verified against the specified public key

I would expect it to fail as the Rekor timestamping cannot be checked without the public key
Am I missing something?

@asraa
Copy link
Contributor

asraa commented Apr 29, 2022

I would expect it to fail as the Rekor timestamping cannot be checked without the public key

This was curious, so I reproduced it and wanted to check what was going on with cosign.

The path that this takes it the following:

  1. VerifyImageSignature with a not-nil co.SigVerifier and a not-nil co.RekorClient
  2. verifyOCISIgnature since we have a not-nil co.SigVerifier. This is successful.
  3. Continue to VerifyBundle. This returns bundleVerified = false because, like you noted, you did not cosign initialize so the bundle was not verified with the rekor public key.
  4. Move on to validate on an online rekor client, by entry in this conditional
  5. Validate the tlog public key here because we have a SigVerifier. This returns no error. see below, i think this is a bug

Note that this line was not printed in your output because the bundle could not be verified

fmt.Fprintln(os.Stderr, " - Existence of the claims in the transparency log was verified offline")

The reason why this is happening is because in (5) we FindTlogEntry but we do not VERIFY tlog entry (

_, err = FindTlogEntry(ctx, rekorClient, b64sig, payload, pemBytes)
).

I think this is a bug. We should add a call to VerifyTlogEntry following retrieval of it. Similar to the code for tlogValidateCertificate

Thinking this through the current code just asks rekor if it had the entry with that UUID. It trusts rekor, and does not verify an inclusion proof or a signed entry. I think we should verify it.

WDYT @bobcallaway @haydentherapper

@haydentherapper
Copy link
Contributor

Very much agree, we should be verifying anything we find in Rekor. By initializing a specific Rekor public key, you are saying I trust the log that is associated with this key. Without verification, then the client blindly trusts whatever Rekor log is provided.

@dlorenc
Copy link
Member

dlorenc commented May 2, 2022

cc @wlynch can you grab this one?

@wlynch
Copy link
Member

wlynch commented May 2, 2022

cc @wlynch can you grab this one?

sure thing! I'll take a look today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants