Amazon has security critical functionality on an unauthenticated http endpoint on a link local address. That's pretty damn dumb in my book.

Support for your assertion: https://rhinosecuritylabs.com/cloud-security/aws-security-vu...

That's a great link, but they're looking at "misconfigurations". How is that relevant here?

> Since the metadata service doesn’t require any particular parameters, fetching the URL http://169.254.169.254/latest/meta-data/iam/security-credent... will return the AccessKeyID, SecretAccessKey, and Token you need to authenticate into the account.

They talk about the AWS “Metadata Service” Attack Surface and how juicy a target it is. I was just providing support for that opinion.

Yes, software that runs on the instance can learn instance metadata. No, that is not a problem. Running e.g. user-supplied scripts on the instance would be "pretty damn dumb", but no one is that dumb. Any widely distributed software that did something shady with instance metadata would get busted PDQ. Just like any widely distributed software that did something shady with e.g. root credentials, which is about the same threat scenario.

It's crappy design which bypasses important security mechanisms of the OS (lower privileged users) by allowing every application with network access to access such critical functionality. One sane approach would be passing this information to the OS through the hypervisor which then exposes it as a properly ACLed file system.

This is like an author of a website vulnerable to CSRF (because it relies on IP for auth) blaming browsers for allowing cross site requests instead of require proper authentication. Except that Amazon is powerful enough to get away with pushing all the effort onto developers and admins.

You can use iptables to limit metadata access to certain users but that takes effort so no-one does it.

I guess a machine-local service that takes ownership of the metadata service and implements additional restrictions (such as limiting access keys to privileged users) might be doable.

Yes, in some situations it will take effort to not allow network access to untrusted software and/or users. For those situations, EC2 is not a good fit.

How is it “obviously” the right policy? If implemented, console input would presumably be part of the AWS API, guarded with IAM permissions like everything else. If you have full IAM permissions, you can already take over any instance by temporarily attaching its disk to a different instance and modifying the data from there. (That requires rebooting, but so would takeover via console input.) Indeed, I’ve had to do exactly that on multiple occasions to fix broken config files on my personal instance; it would have been much more convenient to have console input.

This "personal instance" model doesn't really fit AWS: if the instance is borked then fail over to another one that isn't. No need for console input.

FreeBSD has an interactive kernel debugger that you can use with a serial console. Super useful to track down some things, not usable on AWS -- you'd need to (somehow) do a core dump and hope you can figure it out from there.