4 ms·

Isn't IMDSv2 still insecure against attackers who can initiate arbitrary http requests? I really don't get why all big cloud providers are so keen to preserve t

Isn't IMDSv2 still insecure against attackers who can initiate arbitrary http requests? I really don't get why all big cloud providers are so keen to preserve that vulnerability.

mnutt 4y ago
The AWS article and docs on IDMSv2 really bury the lede and people may take away “protects against SSRF” when AWS should really say “protects against SSRF for GET/POST methods only”. It’s fine as an additional layer but they kind of oversell it.
- amluto 4y ago
  I don’t get why IDMS is TCP at all. IMO these services should be designed so that the VM root user can access them using an out of band mechanism only and VM non-root users cannot access them at all without explicit action from root. It’s dorky, but 9pfs over virtio would work for this purpose, at least with a Linux guest.
  - sylens 4y ago
    At some point though you start making it too hard for legitimate applications and services to make use of the original purpose of the service. IMDSv2 is really aiming to do two things: 1. Require a session to access credentials. You can only initiate the session with a PUT request to prevent some reverse proxy and WAF misconfigurations from becoming the front door. If your reverse proxy still supports PUT requests, IMDSv2 is going to reject anything with an X-Forwarded-For header 2. Once the session is established, it can only be used from the instance where the session began as you get an instance-specific token - so you can't take credentials and then plug them into your own client to start exfiltrating data
    - amluto 4y ago
      Reading a value out of /sys/fs/idms/key seems like just the right amount of barrier to entry. Most languages and environments support this out of the box with a line or two of code. Some may treat it as a privileged operation, which is a good thing. Operations like fetch() can only read it if they’re wildly misconducted so they have local filesystem access, which is a rather higher barrier to entry than plain SSRF. And this supports regular file modes and ACLs, whereas getting this right with iptables/nftables is awkward at best and requires enabling a firewall.
  - staticassertion 4y ago
    It's pretty easy to restrict which users can access IMDS, if you want to do that.
    - amluto 4y ago
      The problem is that the default is wide open.
      - staticassertion 4y ago
        I'm not sure what can really be done about that while still allowing custom AMIs with arbitrary operating systems. "Talk to local network" is a pretty generic interface.
        amluto 4y ago
        AMIs are already specialized for virtualization. To get full performance, guests need a whole pile of specialized drivers. Most are industry standards, but they’re still specialized for VM. Adding one more for IDMS v3 and similar mechanisms from other providers seems straightforward to me.
colmmacc 4y ago
IMDSv2 lead here! Overall the IMDS is a pretty massive security win ... it means that software and scripts can use short-lived ephemeral credentials that are tied to an instance role very easily. That rules out the kinds of credential leakage issues mentioned in this article, but also filesystem traversal issues and so on that have been common in software historically. That's the big why. It's a HTTP interface so that the most software can benefit from that, whether it's a shell script using curl or something written in Java, Scala, Python, Node.js, Rust, whatever ... pretty much everything can make HTTP requests. Of course over time that HTTP interface became a target itself and when applications have SSRF issues, badness could ensue. IMDSv2 limits the reachability in four ways to protect against SSRF. 1. The IMDS can be entirely turned off if you prefer. 2. Access requires a PUT request, our analysis showed that SSRFs that grant the ability to PUT are very rare. Most SSRF issues only grant GET because they are a URL or header escaping issue that don't give up control of the method. 3. Requests with X-Forwarded-For are denied, so if it's a misconfigured open proxy or WAF that adds this header, you get protection. 4. The request has to come from the local box because we set the IP TTL to "1" which means it isn't routable off-box. This protects against misconfigured NATs and routers.

Isn't IMDSv2 still insecure against attackers who can initiate arbitrary http requests? I really don't get why all big cloud providers are so keen to preserve that vulnerability.

mnutt 4y ago

The AWS article and docs on IDMSv2 really bury the lede and people may take away “protects against SSRF” when AWS should really say “protects against SSRF for GET/POST methods only”. It’s fine as an additional layer but they kind of oversell it.

amluto 4y ago
I don’t get why IDMS is TCP at all. IMO these services should be designed so that the VM root user can access them using an out of band mechanism only and VM non-root users cannot access them at all without explicit action from root. It’s dorky, but 9pfs over virtio would work for this purpose, at least with a Linux guest.
- sylens 4y ago
  At some point though you start making it too hard for legitimate applications and services to make use of the original purpose of the service. IMDSv2 is really aiming to do two things: 1. Require a session to access credentials. You can only initiate the session with a PUT request to prevent some reverse proxy and WAF misconfigurations from becoming the front door. If your reverse proxy still supports PUT requests, IMDSv2 is going to reject anything with an X-Forwarded-For header 2. Once the session is established, it can only be used from the instance where the session began as you get an instance-specific token - so you can't take credentials and then plug them into your own client to start exfiltrating data
  - amluto 4y ago
    Reading a value out of /sys/fs/idms/key seems like just the right amount of barrier to entry. Most languages and environments support this out of the box with a line or two of code. Some may treat it as a privileged operation, which is a good thing. Operations like fetch() can only read it if they’re wildly misconducted so they have local filesystem access, which is a rather higher barrier to entry than plain SSRF. And this supports regular file modes and ACLs, whereas getting this right with iptables/nftables is awkward at best and requires enabling a firewall.
- staticassertion 4y ago
  It's pretty easy to restrict which users can access IMDS, if you want to do that.
  - amluto 4y ago
    The problem is that the default is wide open.
    - staticassertion 4y ago
      I'm not sure what can really be done about that while still allowing custom AMIs with arbitrary operating systems. "Talk to local network" is a pretty generic interface.
      - amluto 4y ago
        AMIs are already specialized for virtualization. To get full performance, guests need a whole pile of specialized drivers. Most are industry standards, but they’re still specialized for VM. Adding one more for IDMS v3 and similar mechanisms from other providers seems straightforward to me.

colmmacc 4y ago

IMDSv2 lead here! Overall the IMDS is a pretty massive security win ... it means that software and scripts can use short-lived ephemeral credentials that are tied to an instance role very easily. That rules out the kinds of credential leakage issues mentioned in this article, but also filesystem traversal issues and so on that have been common in software historically. That's the big why. It's a HTTP interface so that the most software can benefit from that, whether it's a shell script using curl or something written in Java, Scala, Python, Node.js, Rust, whatever ... pretty much everything can make HTTP requests. Of course over time that HTTP interface became a target itself and when applications have SSRF issues, badness could ensue. IMDSv2 limits the reachability in four ways to protect against SSRF. 1. The IMDS can be entirely turned off if you prefer. 2. Access requires a PUT request, our analysis showed that SSRFs that grant the ability to PUT are very rare. Most SSRF issues only grant GET because they are a URL or header escaping issue that don't give up control of the method. 3. Requests with X-Forwarded-For are denied, so if it's a misconfigured open proxy or WAF that adds this header, you get protection. 4. The request has to come from the local box because we set the IP TTL to "1" which means it isn't routable off-box. This protects against misconfigured NATs and routers.