I've described it previously as "Kerberos for the AWS Cloud" (which will make any self-respecting crypto nerd squirm) but hopefully it conveys the general idea. Yes it was designed for mobile & browser use, and yes the API isn't pretty, but it's there.

edit: not sure why the downvote, I use Google Cloud, so honest question :(

Some limited instance info about your host ID, fault domain, and update domain: curl http://169.254.169.254/metadata/v1/InstanceInfo

Poll this regularly to find out when your VM is about to go down for maintenance: http://169.254.169.254/metadata/v1/maintenance

Those are the only two endpoints I know of. I encouraged them to require a special header for access to this API before releasing to the public but it looks like it was not included. A special header would help prevent your app from being able to access this from a user specified URL.

Google requires a header to help prevent this: https://cloud.google.com/compute/docs/storing-retrieving-met...

I try to limit the possibility of abuse (restricting protocol to http, https, //, data, or ftp) but didnt know about this metadata issue.

I updated my product to account for this issue too.

it looks like google's metadata doesn't leak any important secrets (unless I had custom metadata, which i do not) but better safe than sorry!

It's well documented and very useful feature in aws and it also exists in gcloud, although gcloud documentation is not as good^1.

It only becomes a vulnerability if you don't read the documentation AND don't follow best practices^2.

I don't know if azure provides this feature.

^1 I use gcloud now and have used aws in the past.

^2 Don't run unknown code without proper sandboxing

Like Colin pointed out in the blog post, this completely subverts the permissions model in modern operating systems.

Calling this a vulnerability is akin to calling the existence of `rm` a vulnerability because it can delete files.

I allow usage patterns similar to what is being described, so it is a vulnerability in something, be it my fault or not.

169.254.0.0/16 is link-local range which you should be flitering along with publicly routable ip ranges that might be very upset if you access them like .mil reserved ip ranges. Go as far to also only allow DNS names instead of arbitrary ip, keeping in mind dns names may resolve to non publicly routable ranges or ranges you may not wish to access. These are all standard dangers of making queries on a user's behalf.

Good list of ipv4 ranges you should not allow: https://github.com/robertdavidgraham/masscan/blob/master/dat...