
Locking Down the Instance Metadata Service: Announcing Imds-Filterd - cperciva
http://www.daemonology.net/blog/2020-01-27-Announcing-imds-filterd.html
======
arkadiyt
This is great defense in depth but if someone gets RCE on your host then I
would assume that entire box is compromised. Local privilege escalation is
very frequently possible, only costs ~$50k for a 0day [1] and there are tons
of free PoCs available if you don't keep your systems fully patched.

The protection I would highly recommend everyone use is enabling Amazon's "v2"
metadata service [2] in enforce mode, which will neuter nearly all SSRF
metadata attacks. This won't do anything if someone has RCE on your host, but
it would have prevented the Capital One breach the author uses as their
example. Nearly every metadata compromise in recent history has been through
SSRF.

Another aspirational read is how Netflix detects credential compromise [3]:
the first time a host asks for metadata credentials they save its ip address,
and if they ever see those credentials used from a different ip address they
alert on it.

[1]: [https://zerodium.com/program.html](https://zerodium.com/program.html)

[2]: [https://aws.amazon.com/blogs/security/defense-in-depth-
open-...](https://aws.amazon.com/blogs/security/defense-in-depth-open-
firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/)

[3]: [https://netflixtechblog.com/netflix-cloud-security-
detecting...](https://netflixtechblog.com/netflix-cloud-security-detecting-
credential-compromise-in-aws-9493d6fd373a)

~~~
cperciva
_Local privilege escalation is very frequently possible_

I would say that how frequently it's possible depends on the context. If
someone gets RCE as user nobody running inside /var/empty, there's a wide
range of vulnerabilities which they would be unable to utilize. Even more so
if they're locked down with Capsicum or other sandboxing tools.

People talk about RCE as if it's a single category, but there are many cases
where someone might be able to execute arbitrary code inside a sandbox while
not having the ability to execute arbitrary code on the host system.

------
all_blue_chucks
Does this provide any advantages over the Instance Metadata Service v2 that
launched last year?

[https://aws.amazon.com/blogs/security/defense-in-depth-
open-...](https://aws.amazon.com/blogs/security/defense-in-depth-open-
firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/)

~~~
cperciva
Yes. IMDSv2 only addresses misconfigured proxies.

------
TrueDuality
Nice! I do currently filter based on username / groups in my firewall policies
on my virtualized Linux hosts which has been pretty effective but yes there
are some places where I've had to give an otherwise unprivileged user the
ability to query the metadata service which is not great. In most cases
restricting this to root is sufficient.

------
zokier
Does the packet filter vs routing performance thing apply also on Linux, would
doing this with netfilter add perf overhead and do people run Linux without
netfilter in high-load environments? Is using route tables instead a valid
pattern that should be applied also more widely?

~~~
cperciva
_Does the packet filter vs routing performance thing apply also on Linux_

I haven't looked at the Linux kernel code, but keeping routes cached per-flow
is a trivial optimization; I'd be shocked if they weren't using it.

