sec(iac/aws): aws-target CloudFormation accepts the all-zeros OIDC thumbprint for any issuer

[cristim]

Reviewed commit: be11bdcb5. Note: origin/main moved to 3e9660d06 during the review; re-verify against current main before changing code, since a finding may have been fixed or moved.

Blast radius: a template customers deploy into their own AWS accounts. This is not internal CI infrastructure. The affected stack grants irreversible multi-year spend authority in the customer's account, which is why this carries priority/p0 / severity/critical / impact/all-users rather than the priority/p1 / impact/internal used for our own deploy-identity findings.

Where

• iac/federation/aws-target/cloudformation/template.yaml:42-50 (OIDCThumbprint parameter, default all-zeros, validated only as 40 hex characters)
• iac/federation/aws-target/cloudformation/template.yaml:75-76 (where it is used)
• iac/federation/aws-target/terraform/variables.tf:79-87 (the sibling guard that this template lacks)

What

The CloudFormation template accepts the all-zeros placeholder thumbprint for any issuer URL. Its only validation is an AllowedPattern requiring 40 hexadecimal characters, which the all-zeros string satisfies.

The Terraform sibling treats this as unacceptable and rejects the placeholder unless the issuer is one AWS validates natively (login.microsoftonline.com or accounts.google.com), with the reasoning recorded in the validation message:

the all-zeros value bypasses the CA-chain check entirely

Failure scenario

A customer points the CloudFormation template at a self-hosted or third-party OIDC issuer and leaves OIDCThumbprint at its default. AWS then performs no CA-chain validation on the issuer's TLS certificate. An attacker who can MITM or DNS-hijack the issuer's JWKS endpoint mints tokens that sts:AssumeRoleWithWebIdentity accepts, landing in a role that holds ec2:PurchaseReservedInstancesOffering, savingsplans:CreateSavingsPlan, and rds:PurchaseReservedDBInstancesOffering (template.yaml:96-149). The result is irreversible multi-year spend commitments in the customer's account.

The customer has no signal that anything is wrong: the stack deploys cleanly, onboarding reports success, and the difference between this and the Terraform path is invisible unless they read both.

Fix direction

Port the Terraform guard into the template. Either:

• add a Condition that fails the deployment when OIDCThumbprint equals the all-zeros value and OIDCIssuerURL is not one of the AWS-natively-validated issuers (a Fn::If selecting a deliberately-invalid resource, or an AWS::CloudFormation::Init-style assertion), or
• add a Lambda-backed custom resource that validates the thumbprint against the issuer's live certificate chain and fails the stack on mismatch.

Whichever is chosen, the all-zeros default should be removed so a customer must make an explicit choice.

Related

• sec(iac): onboarding paths drift - shell/CFN/ARM templates lack the guards their Terraform siblings enforce cloud-commitments-platform#91 (sec(iac): onboarding paths drift) lists this as instance 4 of the cross-cutting pattern. That issue tracks the missing parity mechanism (CI parity tests across onboarding paths); this issue tracks the individual fix to this template, which is needed regardless of whether the parity mechanism lands.
• sec(iac): aws-target CloudFormation makes the OIDC sub restriction optional; the default trusts every identity from the issuer #1543 covers the sibling defect in the same file: OIDCSubjectClaim defaulting to empty so the trust policy has no :sub condition. Both defects are in the same trust policy and should be fixed in one pass, but they are independent (fixing one leaves the other exploitable).

[cristim]

Re-triage: p0/critical → p2/medium

An independent adversarial review of PR #1678 tested this issue's threat model against current AWS documentation (both pages fetched and quoted verbatim, not paraphrased). The mechanism this issue describes does not exist, so the severity is being corrected. The fix in #1678 is still worth landing — see below.

What the issue claims

AWS then performs no CA-chain validation on the issuer's TLS certificate

What AWS actually documents

From Obtain the thumbprint for an OIDC identity provider:

AWS secures communication with OIDC identity providers (IdPs) using our library of trusted root certificate authorities (CAs) to verify the JSON Web Key Set (JWKS) endpoint's TLS certificate. If your OIDC IdP relies on a certificate that is not signed by one of these trusted CAs, only then we secure communication using the thumbprints set in the IdP's configuration. AWS will fall back to thumbprint verification if we are unable to retrieve the TLS certificate or if TLS v1.3 is required.

So the thumbprint value cannot disable CA-chain validation:

• Primary path (JWKS certificate chains to a trusted root — both documented issuers, and any realistic hosted IdP): the thumbprint is not consulted at all. All-zeros, a correct thumbprint, and an omitted list are indistinguishable. The CA-chain check runs regardless.
• Fallback path (private CA, certificate unretrievable, or TLS 1.3 required): the thumbprint is consulted — and all-zeros is not the SHA-1 of any certificate, so it matches nothing and every AssumeRoleWithWebIdentity fails. It fails closed.

There is no documented sentinel meaning for an all-zeros value, and even if it were treated as "no thumbprint" that degrades to the omitted case, where IAM retrieves the real thumbprint. Neither is a bypass.

The MITM/DNS-hijack attacker in the issue's scenario must still present a certificate signed by a CA in AWS's trusted-root library, and that bar does not move with this parameter. There is therefore no path from this defect to assuming the commitment-purchasing role.

Note also that the AWS page names no IdPs — the older "Auth0, GitHub, GitLab, Google, S3-hosted JWKS" phrasing that the Terraform module's rationale rests on is outdated. The module comment "the all-zeros value bypasses the CA-chain check entirely" describes a mechanism that does not exist.

What the real defect is

1. Availability — on the fallback path the shipped default guarantees auth failure. It converts "verify" into "always fail".
2. Misleading documentation — the current text ("Leave as zeros only for well-known providers where AWS auto-validates the chain") tells operators the value matters for other issuers, when it is unread for every publicly-trusted issuer and actively breaks private-CA ones.
3. No way to express AWS's own default (let IAM retrieve the thumbprint).

That is a genuine foot-gun on a customer-deployed template and worth fixing — but it is not a takeover risk, so severity/critical and impact/all-users overstate it.

Confirmed accurate

The issue's statement that the parameter is "validated only as 40 hexadecimal characters" is correct — origin/main carries AllowedPattern: "^[0-9a-fA-F]{40}$". Only the mechanism claim is wrong.

Label change

priority/p0 → p2, severity/critical → medium, urgency/now → this-sprint, impact/all-users → few. Keeping type/security — the misleading-documentation aspect is security-adjacent even though the exploit is not real.

Leaving the original issue text intact rather than editing it; this comment is the correction of record. Flagging for the same reason to anyone working LeanerCloud/cloud-commitments-platform#91 or #1543, which may have inherited the same model.