ANN: DNS resolver changes in yakkety

Marc Deslauriers marc.deslauriers at canonical.com
Tue May 31 20:08:21 UTC 2016


On 2016-05-31 03:52 PM, Stéphane Graber wrote:
> On Tue, May 31, 2016 at 09:38:51PM +0200, Martin Pitt wrote:
>> Hello Stéphane,
>>
>> Stéphane Graber [2016-05-31 11:23 -0400]:
>>> So in the past there were two main problems with using resolved, I'd
>>> like to confirm both of them have now been taken care of:
>>>
>>>  1) Does resolved now support split DNS support?
>>>     That is, can Network Manager instruct it that only *.example.com
>>>     should be sent to the DNS servers provided by a given VPN?
>>
>> resolved has a D-Bus API SetLinkDomains(), similar in spirit to
>> dnsmasq. However, NM does not yet know about this, and only indirectly
>> talks to resolved via writing /etc/resolv.conf (again indirectly via
>> resolvconf). So the functionality on the resolved is there, but we
>> don't use it yet. This is being tracked in the blueprint.
> 
> Ok and does it support configuring this per-domain thing through
> configuration files?
> 
> That's needed so that LXC, LXD, libvirt, ... can ship a file defining a
> domain for their bridge which is then forwarded to their dnsmasq
> instance.
> 
> I don't believe we do this automatically anywhere but it was planned to
> do it this cycle for LXD and quite possibly for LXC and libvirt too (so
> you can resolve <container>.lxd or <vm>.libvirt).
> 
>>
>>>  2) Does resolved now maintain a per-uid cache or has caching been
>>>     disabled entirely?
>>
>> No, it uses a global cache.
>>
>>>     In the past, resolved would use a single shared cache for the whole
>>>     system, which would allow for local cache poisoning by unprivileged
>>>     users on the system. That's the reason why the dnsmasq instance we spawn
>>>     with Network Manager doesn't have caching enabled and that becomes even
>>>     more critical when we're talking about doing the same change on servers.
>>
>> Indeed Tony mentioned this in today's meeting with Mathieu and me --
>> this renders most of the efficiency gain of having a local DNS
>> resolver moot. Do you have a link to describing the problem? This was
>> requested in LP: #903854, but neither that bug nor the referenced
>> blueprint explain that.
>>
>> How would an unprivileged local user change the cache in resolved? The
>> only way how to get a result into resolvconf's cache is through a
>> response from the forwarding DNS server. If a user can do that, what
>> stops her from doing the same for non-cached lookups?
>>
>> The caches certainly need to be dropped whenever the set of
>> nameservers *changes*, but this already happens. (But this is required
>> for functioning correctly, not necessarily a security guard).
>>
>> If you have some pointers to the attack, I'm happy to forward this to
>> an upstream issue and discuss it there (or file an issue yourself,
>> tha'd be appreciated). If this is an issue, it should be fixed
>> upstream, not downstream by disabling caching completely.
> 
> I seem to remember it being a timing attack. If you can control when the
> initial DNS query happens, which as an unprivileged user you can by just
> doing a local DNS query and you know what upstream server is being hit,
> which you also know by being able to look at /etc/resolv.conf, then you
> can generate fake DNS replies locally (DNS is UDP so the source can
> trivially be spoofed) which will arrive before the real reply and end up
> in your cache, letting you override any record you want.
> 
> For entries that are already cached, you can just query their TTL and
> time the attack to begin exactly as the cached record expires.
> 
> 
> This would then let an unprivileged user hijack just about any DNS
> record unless you have a per-uid cache, in which case they'd only hurt
> themselves.
> 
> 
> 
> Anyway, you definitely want to talk to the security team :)
> 

My memory is a bit fuzzy, but I believe there were two concerns with a
system-wide cache:

1- a privacy issue. It is trivial for a local user to probe if a site was
visited by another local user.

2- a cache poisoning attack. Because the resolver is local, source port
randomization is futile when a local user can trivially look up which source
port was selected when a particular request was made and can respond with a
spoofed UDP packet faster than the real dns server. No MITM required.

>>
>>> Additionally, what's the easiest way to undo this change on a server?
>>
>> Uninstall libnss-resolve, or systemctl disable systemd-resolved, I'd
>> say.
>>
>>> I have a few deployments where I run upwards of 4000 containers on a
>>> single system. Such systems have a main DNS resolver on the host and all
>>> containers talking to it. I'm not too fond of adding an extra 4000
>>> processes to such systems.
>>
>> I don't actually intend this to be in containers, particularly as
>> LXC/LXD already sets up its own dnsmasq on the host. That's why I only
>> seeded it to ubuntu-standard, not to minimal. The
>> images.linuxcontainers.org images (rightfully) don't have
>> ubuntu-standard, so they won't get libnss-resolve and an enabled
>> resolved.
> 
> But our recommended images are the cloud images and they sure do include
> ubuntu-standard:
> 
> root at xenial:~# dpkg -l | grep ubuntu-standard
> ii  ubuntu-standard                  1.361                           amd64        The Ubuntu standard system
> 
> 
> The images.linuxcontainers.org images are tiny images which some of our
> users prefer over the recommended official ones published on the Ubuntu
> infrastructure. But if the intent is for this change not to affect
> containers, then it also must deal with our recommended images.
> 
>>
>> Thanks,
>>
>> Martin
> 

Marc.





More information about the ubuntu-devel mailing list