4 ms·

You are getting downvoted because it's not a vulnerability. It's well documented and very useful feature in aws and it also exists in gcloud, although gcloud d

You are getting downvoted because it's not a vulnerability. 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

hueving 10y ago
It's borderline a privilege escalation vulnerability. The default behavior is that an unprivileged user on the system with network access can get access to an instance's credentials that can be used to perform administrative functions. Like Colin pointed out in the blog post, this completely subverts the permissions model in modern operating systems.
- subway 10y ago
  No, it is not a vulnerability. Misunderstanding of this functionality can result in developer introducing a vulnerability, but this is a well described, well defined feature. Calling this a vulnerability is akin to calling the existence of `rm` a vulnerability because it can delete files.
novaleaf 10y ago
I didn't mean to suggest it being what it isn't. I allow usage patterns similar to what is being described, so it is a vulnerability in something, be it my fault or not.
- Pharaoh2 10y ago
  If your service allows arbitrary url queries that a user can trigger then you should make sure that you only allow queries to publicly routable ip ranges anyway. 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/data/exclude.conf https://github.com/robertdavidgraham/masscan/blob/master/dat...

hueving 10y ago

It's borderline a privilege escalation vulnerability. The default behavior is that an unprivileged user on the system with network access can get access to an instance's credentials that can be used to perform administrative functions. Like Colin pointed out in the blog post, this completely subverts the permissions model in modern operating systems.

subway 10y ago
No, it is not a vulnerability. Misunderstanding of this functionality can result in developer introducing a vulnerability, but this is a well described, well defined feature. Calling this a vulnerability is akin to calling the existence of `rm` a vulnerability because it can delete files.

novaleaf 10y ago

I didn't mean to suggest it being what it isn't. I allow usage patterns similar to what is being described, so it is a vulnerability in something, be it my fault or not.

Pharaoh2 10y ago
If your service allows arbitrary url queries that a user can trigger then you should make sure that you only allow queries to publicly routable ip ranges anyway. 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/data/exclude.conf https://github.com/robertdavidgraham/masscan/blob/master/dat...