Staged S3 assets might be maliciously replaced before being used

[nakedible]

CDK uses a shared "staging bucket" that is created for an account as part of cdk bootstrap. I believe the intention is to be able to use this bucket for all staged assets across all stacks in the same account/region. However, unless all these stacks share the same security level, this creates a vulnerability window where a malicious actor might replace the contents of an asset after it has been uploaded but before it is used by CloudFormation. This means that through the assets the malicious user can get code running with the credentials of the original user.

Reproduction Steps

• User starts cdk deploy
• CDK uploads assets to staging bucket
• Malicious user notices uploaded asset and replaces the contents with their own
• CDK creates CloudFormation change set
• CloudFormation reads the modified contents of the assets instead of the original

Environment

• CLI Version : 1.12.0
• Framework Version: 1.12.0
• OS : Linux
• Language : TypeScript

Other

The use of a shared staging bucket should not cause any security problems for the user. The way to achieve this is to ensure the staging bucket has versioning enabled, and meticulously use the "version id" obtained during asset upload in every usage.

• CloudFormation supports adding ?versionId=foobar to the template URL, at stack create, update and nested stacks.
• Lambda supports specifying code and layers with S3Bucket, S3Key and S3ObjectVersion

After this, the worst a malicious user with access to the bucket can do is DeleteObjectVersion on the object before it is used, which is a denial of service problem only, and limiting access to that operation is simple, as it is not needed in normal operation unlike PutObject.

I believe Docker assets automatically use the sha256 hash from the image being pushed, so they do not share the same problem.

---

This is :bug: Bug Report

[nmussy]

This sounds very reasonable. The only hurdle that I can see is that current CDK bootstrap buckets do not have versioning enabled, and will need to be updated.

[SomayaB]

Hi @nakedible, thanks for bringing this to our attention. We will look into this right away.

[shivlaks]

Hi @nakedible, Thank you for reporting the issue.

Assets can only be swapped out by a user who has access to the S3 staging bucket. I agree that we can limit the surface area by ensuring we have further in-depth protection when reading and using S3 assets.

I think this issue requires further design to strengthen the usage of S3 assets. Regardless of approach, we should enable versioning for the staging bucket created by running cdk bootstrap for auditability and traceability. Versioning would allow us to maintain the history of objects within the bucket through versions.

This should also be a consideration for cdk-assets which will be used to support continuous delivery.

[RomainMuller]

Using a versioned bucket clearly would tighten some knots here, which is never a bad thing... however I remain a little skeptical at the actual threat here.

Leveraging the vulnerability requires write permissions to the bucket... which looks like the account is already compromised... I might be thinking of it in too simple terms though... I'd like to see a little more detail about the scenarios that are of issue here. (Notwithstanding the design work around tightening the knots as said before)

[nakedible]

Using a versioned bucket clearly would tighten some knots here, which is never a bad thing... however I remain a little skeptical at the actual threat here.

Leveraging the vulnerability requires write permissions to the bucket... which looks like the account is already compromised... I might be thinking of it in too simple terms though... I'd like to see a little more detail about the scenarios that are of issue here. (Notwithstanding the design work around tightening the knots as said before)

Quite simply, if all the users in the same account have the same permissions, there is no vulnerability. However, consider if there are two groups of users, "developers" and "administrators". Developers are allowed a reduced set of operations, where as administrators can do everything. But both use CDK, using the same CDKToolkit stack, and the same staging bucket.

In this setup, when an administrator deploys a CDK stack with a nested stack, the developer can replace the nested CloudFormation stack template uploaded as an asset before CloudFormation can use it, and as such create any resources with administrator permissions instead of developer permissions. Same thing with a Lambda function - the developer can replace the code being updated to a Lambda function before it gets read by CloudFormation, and as such can get code running in a Lambda function they otherwise would not have access to update.

As said, this is not a problem if different security levels use different staging buckets, or if every user has the same permissions - but there is a problem if there are users with different permissions that share the same staging bucket. Granted, not such a big deal, which is why I thought this could be public in GitHub.

[github-actions[bot]]

This issue has not received any attention in 1 year. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

[iliapolo]

keep open

[roskelleycj]

@nakedible states a scenario that would be true if the the organization that is operating the account allows such a use case.

Organizations in general should separate the permissions of dev from admin. In the case of CDK either the devs have a separate account from the admin OR if they are sharing the account then the devs would have access to a different cdk bootstrap from the admin's cdk bootstrap.

In other words all organizations much understand the technology they are using and determine for their organization what the right approach will be to maximize the security of the solution. AWS CDK makes it quite possible to separate the dev/admin concerns.

[github-actions[bot]]

This issue has not received any attention in 1 year. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.