unqualified domain name can cause instance metadata download from untrusted sources

[Florian Weimer]

I see that in cloud-init, you use the URL http://instance-data:8773 to obtain instance metadata, in addition to the more widely used http://169.254.169.254. Is the former really necessary? Depending on the stub resolver configuration, an unqualified host name such as "instance-data" can cause DNS queries across administrative boundaries, which might cause cloud-init to load metadata from untrusted sources. Perhaps switching to http://instance-data.:8773 would work?

[Garrett Holmstrom (gholms)]

The purpose of the instance-data lookup is to make it possible for Eucalyptus instances to obtain metadata when the cloud is in static mode. In static mode 169.254.169.254 doesn't work, so the cloud administrator can add an "instance-data" record to the cloud's subdomain that points to the cloud controller, which hosts instance metadata. Newly-starting instances will then learn that subdomain from DHCP, look up "instance-data" from it, and use the result to locate the cloud controller.

"instance-data." ought to work, but it would make the solution to the above problem somewhat more complex since it involves adding a new TLD that the DNS server doesn't have a signature for.

Does that make sense? Any thoughts?

[Florian Weimer (fweimer)]

Wouldn't it make more sense to fix Eucalyptus so that 196.254.169.254 works in static mode as well? The DNS-based method will always have an increased potential for unintended traffic leaks, especially if you want to make use of the default search path.

[Scott Moser (smoser)]

I may be misunderstanding something, but the lookup for 'instance-data' when it is not terminated will attempt to resolve only in all the domains listed in /etc/resolv.conf, right? default images in ubuntu now have *no* resolv.conf (bug 1042227 has more details), meaning the search list is only populated by dhcp.

At the time 'instance-data' lookup is performed:
 a. initially baked into the image
 b. updated in most cases by dhclient
 c. possibly updated by the user post first-boot, even via user-data (and then managed in coordination with distro network scripts).
 d. possibly inserted by another build process

So when cloud-init comes up and goes looking for 'instance-data', the domains that will be searched are whatever were sent in the dhcp response. I do not think that it would be common (or a good idea) to add '.com' to the search list returned by your dchp server. The attack vector for this would then be either
1.) misconfiguration by the user (c, d)
2.) exploit of dns (entirely possible, but would not be improved by using 'instance-data.'
3.) exploit of dhcp response

In "cloud" scenarios, if a network of an instance is compromised to allow either 2 or 3, then something is seriously wrong. That leaves the most likely vector of attack to be misconfiguration of the user.

Does this analysis seem correct?

[Scott Moser (smoser)]

Note, I talked with Jamie Strandboge and he pointed out that '3' is the most likely vector for attack.
It seems like adding '.' to http://instance-data is the right thing to do.

I'm dns ignorant. Garret, can you explain how much more difficult or invasive it would be to add a top level 'instance-data' entry compared to one under another search domain?

[Florian Weimer (fweimer)]

What happens if DHCP does not provide a search list? What happens if there isn't a domain name, either? A lot of this depends on the DHCP client, and how it is configured to generate resolv.conf. I think there is considerable variance in this area.

I'm concerned mostly with accidental misconfiguration. If DHCP-based attacks are possible, surely the attacker could also hijack the 169.254.169.254 address.

[Garrett Holmstrom (gholms)]

Adding a new TLD like that is really easy if you already have sufficient access to your DNS server. I'm not sure if it's going to work if you're using DNSSEC because named doesn't have a way to mark specific zones as insecure, but at the moment I don't have any better ideas. :-\

[Scott Moser (smoser)]

marking this fix-committed (revno 635)

[Scott Moser (smoser)]

Random bit of information related to this bug.
On EC2:
$ host instance-data.
Host instance-data. not found: 3(NXDOMAIN)
$ host instance-data
instance-data.ec2.internal has address 169.254.169.254

So, the change we put in here would prevent this from working in EC2. Note, though, that the search path includes the IP, so it still works.

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/2285