A tale of a DNS exploit: CVE-2015-7547 | Hacker News Reader

A tale of a DNS exploit: CVE-2015-7547

blog.cloudflare.com

107 pointsjgrahamc14 comments

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

It was a no brainer to tell you guys.

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 .

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

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.

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

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.

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.

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.

If you use public wifi you should really be establishing a VPN connection and then passing all traffic over that, only.

Fair, indeed.

The biggest takeaway is PATCH! NOW! WHY HAVEN'T YOU?! ;)

Patching is hard.

getting owned is even harder.

And patching isn't even that hard.

Reply on news.ycombinator.com