3 ms·

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 G

by 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.

by mnutt 4y ago

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.