ANN: DNS resolver changes in yakkety

Stéphane Graber stgraber at ubuntu.com
Tue May 31 21:26:32 UTC 2016


On Tue, May 31, 2016 at 10:45:24PM +0200, Martin Pitt wrote:
> 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.

stgraber at dakara:~$ netstat -nAinet | grep 53
udp        0      0 172.17.0.51:50662       172.17.20.30:53         ESTABLISHED

That gives me the source ip and port for the current DNS query as an
unprivileged user. I can then spoof a DNS reply that matches this.

The rest then depends on how random the transaction ID is, there have
been attacks related to that in the past:
  https://blogs.technet.microsoft.com/srd/2008/04/09/ms08-020-how-predictable-is-the-dns-transaction-id/

Note that in the case of those attacks, they didn't have nearly as much
information as you would by controling when the query happens and being
able to check the source port immediately.


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.

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.


> > 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
; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.ubuntu.com @172.17.20.30
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24839
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.ubuntu.com.            IN  A

;; ANSWER SECTION:
www.ubuntu.com.     600 IN  A   91.189.89.118

;; Query time: 123 msec
;; SERVER: 172.17.20.30#53(172.17.20.30)
;; WHEN: Tue May 31 17:06:19 EDT 2016
;; MSG SIZE  rcvd: 59

stgraber at dakara:~$ dig www.ubuntu.com @127.0.0.1
; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.ubuntu.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63104
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.ubuntu.com.            IN  A

;; ANSWER SECTION:
www.ubuntu.com.     594 IN  A   91.189.89.118

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue May 31 17:06:25 EDT 2016
;; MSG SIZE  rcvd: 59



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.

> Thanks,
> 
> Martin
> 
> -- 
> 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/20160531/d9b8ec1a/attachment.pgp>


More information about the ubuntu-devel mailing list