Wednesday 1 June 2016

Re: ANN: DNS resolver changes in yakkety

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.

> > > 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?
>
> stgraber@dakara:~$ dig www.ubuntu.com @172.17.20.30
> www.ubuntu.com. 600 IN A 91.189.89.118
>
> stgraber@dakara:~$ 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.

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.

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.

Thanks!

Martin

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

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

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)