ANN: DNS resolver changes in yakkety

Wed Jun 1 14:18:25 UTC 2016

On Wed, Jun 01, 2016 at 09:37:51AM +0200, 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.

Indeed, my way of doing it wouldn't work, however you can flip it around
and make it work.

Since any packet with the wrong transaction id invalidates the whole
request and because you don't randomize the source port, all I have to
do is have my helper machine flood the target with fake responses for
all the DNS records I care about using transaction ID 0.

Any request to those records which doesn't use transaction ID 0 will
immediately fail, so I just need to query it in a loop on the target
machine until I hit the right transaction ID and there you go, cache
poisoned.

Source port randomization would make things slightly more difficult in
that I would need communication between the target and helper machine to
communicate what source port to use. Still very far from impossible though.

So this attack would effectively DoS the record until the bad value
makes it to the cache, ensuring that the local user can only connect to
the poisoned record. And again, with doing a query loop on the target,
you should be able to hit the right transaction id reasonably quickly,
once you do, your fake record can have as big a TTL as you want, so
you'll be good for quite a while.

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

> -- 
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20160601/94d163a0/attachment.pgp>