chore(bootstrap): prevent confused deputy

[scarytom]

This role is susceptible to cross-account confused deputy. Adding a condition prevents this.

see https://docs.aws.amazon.com/transcribe/latest/dg/security-iam-confused-deputy.html

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: 66d02be
• Result: FAILED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[rix0rrr]

I'm not necessarily against this change, but two things I'd like to clear up before we merge this:

1. In light of chore(cdk): boostrap template uses deprecated AccessControl property #27764 having to be reverted: how confident are you in this change? What did you do to validate it?
2. Can you describe the attack vector? How would an attacker exploit the absence of this Condition? Please be specific in describing the attack (for example: "an attacker using account 11111 has an IAM policy set up like this: xyz, performs API calls A, B and C, and now has made changes to account 22222)

[scarytom]

1. In light of chore(cdk): boostrap template uses deprecated AccessControl property #27764 having to be reverted: how confident are you in this change? What did you do to validate it?

We have deployed this change in our own infrastructure and CDK continues to operate flawlessly. Unlike #27764, this change makes things less permissive, so it can't open a security flaw for users with a legacy setup.

2. Can you describe the attack vector? How would an attacker exploit the absence of this Condition? Please be specific in describing the attack (for example: "an attacker using account 11111 has an IAM policy set up like this: xyz, performs API calls A, B and C, and now has made changes to account 22222)

We recently paid for a penetration test and security audit of our AWS infrastructure and they flagged this cdk role as a potential risk of confused deputy. I don't know exact steps to reproduce, but the general idea is that this role trusts the cloudformation service and it might be possible to trick that service into assuming the cdk role in another account. This additional condition ensures that is never possible. I suspect that an actual exploit for this doesn't exist out there in the wild right now, but making this change adds defence in depth.

[rix0rrr]

it might be possible to trick that service into assuming the cdk role in another account

I'm pretty sure this is not possible for 2 reasons:

• It's not possible to initiate a cross-account CloudFormation operation
• Even if it were possible to do the previous, you need iam:PassRole permissions to pass the execution role. iam:PassRole is not a permission that can be granted cross-account either.

For both of these reasons, this is not exploitable, nor is it ever likely to be.

• Even if CloudFormation were to support cross-account operations (unlikely) there would still be the PassRole check.
• Even if the PassRole check were to be made possible cross-account (unlikely), it would require a resource policy change to allow the cross-account access (i.e., a change to AssumeRolePolicyDocument), so it still wouldn't allow access.

[kaizencc]

@scarytom, looks like our stance is that we don't have an exploitable issue here. Unless you have a rebuttal, I will close this PR in a bit.

[kaizencc]

Closing this because it's not a PR we are accepting as of now. @scarytom if you would like to continue this conversation, please open a discussion or an issue and tag @kaizencc or @rix0rrr and we can continue there.