This is bullshit and their own report indicates the opposite. Hugely irresponsible of Orca to include this kind of unfounded speculation in their report. But also this is what AWS gets for having a "if there's no customer impact, there's no disclosure" security policy, it leaves the door open for this kind of shit.
There appears to be a denial of components of this from senior AWS figures, not a blanket denial but I think some of the statements could be a potential overreach.
An irresponsible researcher will either say "I'm gonna publish because I think it's high impact" and not give a date (and then often publishing with no notice on a Friday afternoon) or won't even provide notice.
It's often impossible to know which type of actor you're dealing with until it's too late. I've even had people claim they won't publish until X date and then publish early. You can't just provide public notice or you'll both piss off the researcher and run the risk of accidentally giving the impression a low impact bug is actually high impact.
Not saying that it’s a certainty it’s not, but if you make such a claim, you should better have some evidence to back it up.
More detail from Colm here.
That is really fast. It reminds me of the Google DHCP takeover vuln that Google sat on for 9 months (https://github.com/irsl/gcp-dhcp-takeover-code-exec).
Actually seems like, out of the 2 vulnerabilities that were discovered: the one in AWS Glue is more severe, actually gaining cross-tenant data access to some services (Glue & S3, affecting all present and past Glue users).
Also, AWS released bulletins confirming this.
- AWS Glue - https://aws.amazon.com/security/security-bulletins/AWS-2022-...
- CloudFormation - https://aws.amazon.com/security/security-bulletins/AWS-2022-...
They tried it on their own account and were denied. AWS uses these crypto tokens, so it's request -> IAM signed -> Cloudformation -> S3.
Is there maybe a gap where if someone is using S3 a lot, the forward session token thing can be worked around (ie, the Cloudformation service WOULD still have a valid token for another accounts S3 bucket)?
The easy thing here is set up 2 accounts, and actually test it. Curious why they didn't do that.
Or is the scope down to request for X object by Y customer, which is then signed / token attached by IAM, valid for a little bit. That would reduce radius a lot.
Kind of bummed they hyped this one because the Glue one is more interesting to me an a more credible route I thought.