I was expecting some obscure bug in signature verification or something but nope it’s a basic tempfile attack, the sort most of us learned how to avoid in shell scripts decades ago.
Sadly I've barely been writing shell scripts for multiple decades, so needed to look this up.
> If an attacker pre-creates the file with relaxed access permissions, then data stored in the temporary file by the application may be accessed, modified or corrupted by an attacker.
For those who don't have the time to read the entire thing.
The “Shadow Resources” attack vector, which has since been addressed by AWS, stemmed from the automatic generation of S3 buckets by various AWS services, including:
> [...] the researchers note that their findings demonstrate the importance of treating potential identifiers, such as AWS account IDs, as secrets
Which seems to be pretty opposite to the prevailing opinion, at least in some circles. For example the comments here [0] about how to get the account ID for an arbitrary S3 bucket, where many said it was essentially a nothing burger, similar to IP's or emails.
Regardless of who is correct, I think it's a telling example of the "dangers" with identifiers that are kinda-public-kinda-private. I'm guessing at least part of the root cause of this bug are AWS engineer's not thinking about the fact that account ID's aren't fully private.
Though Amazon has protection against confused deputies for Principals , even within an account (every principal has a unique ID, and is account scoped), it doesn't have the same for Resources.
And s3 buckets are not scoped to an account and their ARN is global and doesn't contain the account id.
For the same reason i advice anybody to always use random suffixes (easily done in Terraform with name_prefix) when generating bucket names.
It has been 3 years since I reported a problem in one of their services and they still haven't found anyone who seems to even be able to understand the problem.
Not sure I'm really surprised. As far as I know, AWS hasn't been the fastest in resolving issues. I just remember the "S3 Bucket - We Charge You For Unauthorized Requests" issue a few months ago
chuckadams|1 year ago
normie3000|1 year ago
> If an attacker pre-creates the file with relaxed access permissions, then data stored in the temporary file by the application may be accessed, modified or corrupted by an attacker.
https://owasp.org/www-community/vulnerabilities/Insecure_Tem...
jmisavage|1 year ago
The “Shadow Resources” attack vector, which has since been addressed by AWS, stemmed from the automatic generation of S3 buckets by various AWS services, including:
- CloudFormation
- Glue
- EMR
- SageMaker
- ServiceCatalog
- CodeStar
filleokus|1 year ago
> [...] the researchers note that their findings demonstrate the importance of treating potential identifiers, such as AWS account IDs, as secrets
Which seems to be pretty opposite to the prevailing opinion, at least in some circles. For example the comments here [0] about how to get the account ID for an arbitrary S3 bucket, where many said it was essentially a nothing burger, similar to IP's or emails.
Regardless of who is correct, I think it's a telling example of the "dangers" with identifiers that are kinda-public-kinda-private. I'm guessing at least part of the root cause of this bug are AWS engineer's not thinking about the fact that account ID's aren't fully private.
[0]: https://news.ycombinator.com/item?id=39512896
arianvanp|1 year ago
And s3 buckets are not scoped to an account and their ARN is global and doesn't contain the account id.
For the same reason i advice anybody to always use random suffixes (easily done in Terraform with name_prefix) when generating bucket names.
hypeatei|1 year ago
Never used AWS, but how does it handle auth for data plane operations then?
flerchin|1 year ago
jay-barronville|1 year ago
minkles|1 year ago
noctarius|1 year ago
unknown|1 year ago
[deleted]