[zaltekk]

I'm not sure if I'm reading this correctly. The statements below are my understanding, but it'd be great if you can confirm to provide more color.

The pre-patch setup would just make the implicit trust policy explicit, meaning any user or role in the account with `sts:AssumeRole` on `*` could assume the role (which is still the default when not trust policy is specified).

This change improves the posture by adding a trust policy to the role that prevents any roles other than those two listed from assuming the role. So this is purely a defense in depth measure, and not really a security vulnerability (unless we say the default, implicit trust policy is a security vulnerability itself :P).

[kichik]

Another default policy to consider is any Lambda function role. They never specify which Lambda can assume them (because that would create a cyclical dependency). That means anyone with permissions to create a Lambda will be able to technically assume this role.

Just like you, I'm not arguing the defense in depth part. Always a good idea to put fine-grained permissions where possible. But I also find the "vulnerability" part a tiny bit overstated.

[runamok]

That's a bit different and (like ec2 and other services) governed by IAM:Passrole. Whoever creates the lambda or ec2 needs to be allowed to assign that role. Otherwise it would allow privilege escalation.