Wednesday, 1 June 2016

Re: ANN: DNS resolver changes in yakkety

On 2016-06-01 03:37 AM, Martin Pitt wrote:
> Stéphane Graber [2016-05-31 17:26 -0400]:
>> So yes, the random transaction ID sure helps, so long as it's actually
>> random and so long as you get a DNS reply reasonably quickly.
>
> It's reading from /dev/urandom, so pretty much "as random as you can
> get".
>
>> I think your estimate of a minute isn't anywhere near accurate. One
>> could pretty easily pre-generate all 32768 packets in pcap format, just
>> replace the source address and port once known and then inject the whole
>> pcap onto the network much much faster than that.
>
> No, that doesn't work, as I explained in my other reply. You only have
> one shot and then have to wait for the cached entry to time out until
> you get another one. I. e. a chance of 1/65536 in say half an hour,
> which is much worse than having a chance every few minutes or seconds
> if the client does not cache DNS queries.

When the resolver gets the packet with the invalid transaction ID, the query is
cancelled, so it doesn't get cached at all.

>
>>>> 1- a privacy issue. It is trivial for a local user to probe if a site was
>>>> visited by another local user.
>>>
>>> I assume by looking at the time that it takes to get a response?
>>
>> [email protected]:~$ dig www.ubuntu.com @172.17.20.30
>> www.ubuntu.com. 600 IN A 91.189.89.118
>>
>> [email protected]:~$ dig www.ubuntu.com @127.0.0.1
>> www.ubuntu.com. 594 IN A 91.189.89.118
>>
>>
>> The first query shows you the TTL for the record from the recursive
>> server used by the local resolver, here we see it's 600 seconds, the
>> second request hits the local cache which returns a TTL of 594 seconds.
>> Meaning that the DNS record was accessed by someone on the machine
>> within the last 6 seconds.
>>
>> Do that with some sensitive website and you can know when someone on the
>> machine accessed it.
>>
>> Note that the above wasn't done through resolved.
>
> Exactly :-) So this is unrelated as dig doesn't use nsswitch and thus
> isn't affected by how we configure resolved.
>
> However, you can still look at the time it takes. When I try this with
> a site that I haven't called in ages:
>
> $ time host www.cnn.com
> www.cnn.com is an alias for turner.map.fastly.net.
> turner.map.fastly.net has address 185.31.19.73
> real 0m0.170s
>
> $ time host www.cnn.com
> www.cnn.com is an alias for turner.map.fastly.net.
> turner.map.fastly.net has address 185.31.19.73
> real 0m0.155s
>
> $ time host www.cnn.com
> www.cnn.com is an alias for turner.map.fastly.net.
> turner.map.fastly.net has address 185.31.19.73
> real 0m0.155s
>
> So there is a measurable time difference when a lookup happens (the
> first time) and when it's cached (the two others).
>
> However: as you demonstrated with dig, you don't necessarily need to
> get this information from the local resolver -- you can look at the
> TTL at the real DNS servers in /etc/resolv.conf with dig.

Assuming the real DNS servers are used by a large number of users, there is a
privacy difference in being able to tell if a user on the local machine has
visited a particular site versus being able to tell if any one of the large
number of users has queried the DNS server.

>
> So, the current status is:
>
> 1) I'm not convinced yet [1] that disabling caching helps against
> injecting false responses. resolved implements enough of
> https://tools.ietf.org/html/rfc5452 to make local attacks
> impossible, and remote attacks actually harder than without a
> cache.

I think hitting a transaction ID collision within a few seconds with a helper
machine is plausible. Whether caching is enabled or not is the difference
between poisoning your own lookups, or poisoning other user's lookups.

>
> 2) I acknowledge the timing difference between recently visited and
> unvisited addresses, but you can get the same information from
> your real DNS server with more precision.

The real DNS server only allows you to determine if any of your ISP's users have
visited a site. That's quite different than knowing if any local user on a
multiuser machine visited a site.

>
> Thanks!
>
> Martin
>
> P.S. This is a really enjoyable and good discussion, thank you!

Yes, it's quite interesting!

>
> [1] Note, I don't claim "it's impossible", I'm just saying that the
> current arguments aren't sufficient.
>
>
>

Marc.


--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel