using random hostnames to detect dns proxies allows for false positives
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| cloud-init |
Fix Released
|
Medium
|
Unassigned | ||
| cloud-init (Ubuntu) |
Fix Released
|
Wishlist
|
Unassigned | ||
| Xenial |
Fix Released
|
Low
|
Unassigned | ||
| Zesty |
Fix Released
|
Low
|
Unassigned | ||
Bug Description
=== Begin SRU Template ===
[Impact]
Prior to this fix, cloud-init attempts to detect dns redirection by doing
dns queries for a random hostname and two invalid hostnames. Then, if
the result returned for the input value was the same as the response for
the invalid query cloud-init would assume that result was also invalid.
The change was to replace the random string with
__cloud_
This is a valid hostname and resolution will use the 'search' path in
resolv.conf where the other invalid domain names would not.
[Test Case]
The test case for this consists of excercising the the 'is_resolvable_url'
method in cloudinit.util and watching dns queries. To do this, see the
following steps:
a.) start an lxc container
$ release=xenial
$ name=$release-
$ lxc launch ubuntu-
b.) start a dnsmasq server
$ ./run-dnsmasq lxdbr0
...
=== listening on 10.75.205.2/24 ===
# run-dnsmasq is attached and at
# https:/
c.) point /etc/resolv.conf at your server ip
$ lxc exec $name -- sh -c 'exec >/etc/resolv.conf;
echo nameserver 10.75.205.2; echo search foo;'
d.) perform query via is_resolvable_url watch dnsmasq output, expect
to see the random query.
$ lxc exec $name -- python3 -c 'import sys;
from cloudinit.util import is_resolvable_url;
print(is_
e.) upgrade to -proposed version
f.) perform query via is_resolvable_url, expect to *not* see random query.
[Regression Potential]
Immediate regression seems unlikely. Effectively the change in cloud-init
code path was simply to change a dns lookup attempt from rand() to a defined
string.
We chose a random string initially to make it difficult for a dns server to
circumvent cloud-init's attempt to identify dns redirection. The regression
path really then seems to involve a dns redirection service specifically
provding a response for '__cloud_
from does-not-
believing that a apt mirror was valid where it previously would have
identified the dns redirection. The failure would be seen as errors
in package installation or 'apt-get update'.
[Other Info]
Upstream commit at
https:/
Original upstream commit at
https:/
=== End SRU Template ===
The fix that's been applied for bug #974509 checks for the presence of a redirector by looking of three hostnames, and treating as invalid any results pointing to a matching address:
- does-not-
- example.invalid.
- a random, unqualified 32-character alphanumeric hostname.
The last of these carries a small but non-zero risk of colliding with a real hostname, and there's a small but non-zero risk that this host points to the same address as something we care about. If possible, it would be better to not include this random-host lookup in the algorithm, as somewhere, some day, chances are there will eventually be a collision, causing an incomprehensible and unreproducible failure for a user.
Related branches
- Scott Moser: Approve
- Server Team CI bot: Approve (continuous-integration)
-
Diff: 22 lines (+3/-3)1 file modifiedcloudinit/util.py (+3/-3)
| Dimitri John Ledkov (xnox) wrote | #1 |
| Changed in cloud-init (Ubuntu): | |
| status: | New → Confirmed |
| importance: | Undecided → Wishlist |
| Bob Aman (sporkmonger) wrote | #2 |
| Changed in cloud-init: | |
| status: | New → Confirmed |
| importance: | Undecided → Medium |
| Changed in cloud-init: | |
| status: | Confirmed → Fix Committed |
| Launchpad Janitor (janitor) wrote | #3 |
| Changed in cloud-init (Ubuntu): | |
| status: | Confirmed → Fix Released |
| Changed in cloud-init (Ubuntu Xenial): | |
| status: | New → Confirmed |
| Changed in cloud-init (Ubuntu Zesty): | |
| status: | New → Confirmed |
| Changed in cloud-init (Ubuntu Xenial): | |
| importance: | Undecided → Medium |
| Changed in cloud-init (Ubuntu Zesty): | |
| importance: | Undecided → Low |
| Changed in cloud-init (Ubuntu Xenial): | |
| importance: | Medium → Low |
| Chris J Arges (arges) wrote Please test proposed package | #5 |
| Changed in cloud-init (Ubuntu Xenial): | |
| status: | Confirmed → Fix Committed |
| tags: | added: verification-needed verification-needed-xenial |
| Changed in cloud-init (Ubuntu Zesty): | |
| status: | Confirmed → Fix Committed |
| tags: | added: verification-needed-zesty |
| Chris J Arges (arges) wrote | #6 |
| Chad Smith (chad.smith) wrote | #7 |
| tags: |
added: verification-done-xenial removed: verification-needed-xenial |
| Chad Smith (chad.smith) wrote | #8 |
| tags: |
added: verification-done-zesty removed: verification-needed verification-needed-zesty |
| Launchpad Janitor (janitor) wrote | #9 |
| Changed in cloud-init (Ubuntu Xenial): | |
| status: | Fix Committed → Fix Released |
| Chris Halse Rogers (raof) wrote Update Released | #10 |
| Launchpad Janitor (janitor) wrote | #11 |
| Changed in cloud-init (Ubuntu Zesty): | |
| status: | Fix Committed → Fix Released |
| Scott Moser (smoser) wrote Fixed in Cloud-init 17.1 | #12 |
| Changed in cloud-init: | |
| status: | Fix Committed → Fix Released |
| James Falcon (falcojr) wrote | #13 |
Instead of random request, you can check the checksum of:
http://
Which is highly available connectivity check hosted for installer purposes currently and is used by ubiquity.