
A tale of a DNS exploit: CVE-2015-7547 - jgrahamc
https://blog.cloudflare.com/a-tale-of-a-dns-exploit-cve-2015-7547/
======
davidu
Just a small shoutout of thanks to the CloudFlare team who was excellent about
communicating with us at OpenDNS in advance of this disclosure.

As one of the largest recursive DNS infrastructures in the world, they allowed
us enough time to spin up resources to determine if we were vulnerable (we
were not) which was very much appreciated.

We did a small post this morning that also captures some of the history of our
codebase. [https://engineering.opendns.com/2016/02/29/a-brief-
history-o...](https://engineering.opendns.com/2016/02/29/a-brief-history-of-
opendnscache/)

~~~
jgrahamc
It was a no brainer to tell you guys.

------
sn
If you don't need DNS, a workaround that should still be valid is to disable
DNS lookups entirely via the hosts entry in /etc/nsswitch.conf .

~~~
HNexpert
Or you COULD use DNS and just patch, but sure, yeah.

~~~
dsp1234
_If you don 't need DNS_

If you don't need DNS, then why would you keep it in place? As an example, I
have a system that needs to contact exactly 2 hosts (one of which hosts
package updates). So it has DNS turned off and I have a local hosts config. It
seems like using a exploit announcement as an opportunity to review whether
you need the service in question at all is actually good server
administration.

------
edwhitesell
Good writeup, but I'd disagree with the first Takeaway where it mentions WiFi
redirects being done via a DNS hijacking. That is one way to do it, but it's
rare in my experience. Far more common is simply redirecting TCP 80 traffic to
a webserver that issues a re-direct to the captive portal URL.

Source: I've operated various public WiFi networks since 2001

~~~
vavrusa
I reckon that depends on where you are. I don't have any hard data on this,
just a lifetime of disappointment with hotel wifis. It's not the captive
portal on first use what irks me, but continued DNS intercepting after you
pass the captive portal challenge which hampers either DNSSEC, local resolver,
or both. This is not likely to change soon, so DNS folks dream about DNS/HTTP,
DNS/TLS and all that.

Intercepting actual content transfers makes more sense to me than intercepting
name lookups. One thing should be common - once user authenticates, no more
MitMing.

~~~
edwhitesell
I would agree with you. However, there are valid use-cases for "intercepting"
DNS on public WiFi. The most obvious is to block adult content.

One example was a customer operating WiFi in restaurants. If a patron
accessing the WiFi network was looking at adult content on their laptop, the
restaurant owner could be liable for that. I believe it was a "public
nudity/nuisance" law.

~~~
vavrusa
That is consented filtering and that's fine. I do the same thing locally and
I'm okay with a public network operator refusing to serve certain zones
(nudity, malware, illegal content).

Refusing to lookup a name != MitMing every query however, the latter crosses a
fine line (for me) by both lying about answers (redirection to ad pages), and
at the same time preventing users to validate integrity of the answer (or non-
existence proof).

I'm not a lawyer and have no idea how much is this enforceable in terms and
conditions of the service, but common sense tells me that by opting out of the
provided name services liability transfers to patron. If the recursive
resolution was more decentralised, this would have been moot.

