Tuesday, 31 May 2016

Re: ANN: DNS resolver changes in yakkety

Hello Marc,

Stéphane, Marc, thanks for these!

Marc Deslauriers [2016-05-31 16:08 -0400]:
> > 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.

> 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.

ATM resolved uses randomized ID fields (16 bits), which means that you
need an average of 32.768 tries to get an acceptable answer into
resolved, which you can probably do in the order of a minute. It does
not use source port randomization though, which would lift the average
time to the magnitude of a month.

Can you please give a sketch how to look up the source port that the
resolver uses? That'd be a good piece of information for the upstream
bug report too, as it's not at all obvious.

> 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?

Thanks,

Martin

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

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