In non-CA mode, an attacker who has access to the private key of a pinned certificate can:
Present a certificate with the correct public key
Modify the CN in the client certificate to any arbitrary value
Cause Vault to assign the resulting alias.Name to that CN
when I first read your comment, I agreed, but it’s actually a little bit deeper than that.
You have access to the private key of the public key in a certificate. The certificate is making an attestation that the signer has verified that this canonical name belongs to this public key.
You as the holder of the private key that matches the public key in the certificate should not allow you to change what the signer has attested about you.
You're not wrong that there is indeed a significant issue, but the parent isn't wrong either. If the attacker already has a private key you've probably already lost the war. Yes there's a real issue there but by the time an attacker reaches it they're already in the castle's keep.
> the parent isn't wrong either... if the attacker already has a private key you've probably already lost the war.
When you lose your private key, you have lost the war to protect your identity - anyone else can now be you. But in a properly designed system, that should not also compromise the signer.
If I steal your license I can pretend to be you, but I can't make the government say you are 7 feet tall.
You may be making the point that a compromised keystore holding all users public keys may leak the signers private key at the same time it has leaked the victim's private key, but there are many ways the victim's private key can be leaked in most cryptosystems (eg, the victim's private key on their device may be stolen).
This is authz bypass, not authn, right? You're an unprivileged user and can assume privileged roles.
Yes and https://discuss.hashicorp.com/t/hcsec-2024-05-vault-cert-aut... was an earlier authN+authZ bypass in the same code block.
So maybe one step down in severity, though I do not know the details of what HCSEC-2024-05 was fixed with as that was after the fork point. OpenBao moved to full cert pinning (constant-time cert.Raw comparisons) when remediating that one, which meant we were not affected by this variant.