A potential risk in cloudfront-authorization-at-edge which can be used to upload malicious code. about cloudfront-authorization-at-edge

[zolaer9527]

OK, thank you!

[ottokruse]

Hi @zolaer9527

Thanks for the report. Here's our findings:

You mention as first step executing this from CloudShell:

aws sts assume-role --role-arn "arn:aws:iam::747955086145:role/serverlessrepo-cloudfront-LambdaCodeUpdateHandlerR-MTRLVJ4XJCPJ" --role-session-name CLISession

But that is impossible, because that role can only be assumed by the AWS Lambda service (via the trust relationships of the role), so you must have already altered the trust relationship of the role to allow the role to be assumed by your AWS console user?

Here is the definition of the Lambda function:

cloudfront-authorization-at-edge/template.yaml

Line 1144 in 1adb1ed

LambdaCodeUpdateHandler:

Note that the associated role is created automatically by AWS SAM, and should only have a trust relationship to the AWS Lambda service (or there would be a bug in AWS SAM), and I checked a deployment in my own account where this is indeed the case.

You can indeed log the credentials from a Lambda function, and then use those credentials to do what the Lambda function is allowed to do. Normally you wouldn't do this, but as developer with admin privileges you could if you wanted to. There's no surprise there though? Note that this requires you to alter the Lambda function code, to add that logging. Threat actors would not be able to do that.

I believe your scenario is not a plausible threat, unless your AWS account is compromised (in which case you have more pressing concerns):

• Threat actors do not have access to update the trust relationships of the role
• Threat actors cannot assume the role from AWS CloudShell without already being in the AWS console, and having AWS credentials with which they can do very bad things (assuming roles that they weren't supposed to assume)
• Threat actors cannot alter the Lambda function code without already having AWS credentials with which they can do very bad things (changing Lambda function code)

Back to the role itself: the permissions it has are necessary and required for deployment of the solution with CloudFormation. It needs "lambda:UpdateFunctionCode" the permission.

You are right that Lambda function code signing is an option to ensure with great confidence that only code you trust is deployed to Lambda––if you require that level of assurance. This however is beyond the scope of this sample solution. If you want to add it, you can take this sample solution and tweak it to suit your needs.

I will close this issue, let us know if the above didn't address your concern satisfactorily.

[zolaer9527]

Hello @ottokruse, in the trust relationships of the role, I find the principal is "Service": "lambda.amazonaws.com". Does this mean that the role can be assumed by all AWS Lambda functions? If not, how does the AWS implement one-on-one binding between a function and a role?

[ottokruse]

Does this mean that the role can be assumed by all AWS Lambda functions

Yes, but only by Lambda functions within the account.