unqualified domain name can cause instance metadata download from untrusted sources

Bug #1040200 reported by Florian Weimer
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released

Bug Description

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 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?

Related branches

Revision history for this message
Garrett Holmstrom (gholms) wrote :

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 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?

Revision history for this message
Florian Weimer (fweimer) wrote :

Wouldn't it make more sense to fix Eucalyptus so that 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.

Revision history for this message
Scott Moser (smoser) wrote :

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?

Revision history for this message
Scott Moser (smoser) wrote :

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?

Revision history for this message
Florian Weimer (fweimer) wrote :

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

Revision history for this message
Garrett Holmstrom (gholms) wrote :

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. :-\

Revision history for this message
Scott Moser (smoser) wrote :

marking this fix-committed (revno 635)

Changed in cloud-init:
importance: Undecided → Medium
status: New → Fix Committed
Revision history for this message
Scott Moser (smoser) wrote :

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

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.

Scott Moser (smoser)
Changed in cloud-init:
status: Fix Committed → Fix Released
Scott Moser (smoser)
information type: Private Security → Public
Revision history for this message
James Falcon (falcojr) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.