Dan Kaminsky is an expert on DNS security – and he's saying: Patch right God damn now

Re: Buffer overflows in 2016 are an embarrassment

They can't

Actually, they can, and some have. There have been commercial capability-based systems, though the additional complexity means that they have not really caught on.

I can't help feeling that if you've got the spare die space for invisible operating modes running opaque binary blobs for "system management" purposes, the argument for omitting bounds, type and access checking is looking pretty weak.

Re: Lingering in the cache

Also what I read, but it isn't touched on why or how, but most now run dnsmasq (as I do on my home network using a PI, not my router (all that does is route!)) and that somehow fixes the head on attack:

From here:

http://dankaminsky.com/2016/02/20/skeleton/

"Local resolvers are popular anyway, because they mean there’s a DNS cache improving performance. A large number of embedded routers are already safe against the verified on-path attack scenario due to their use of dnsmasq, a common forwarding cache."

Re: Lingering in the cache

In which case, the router itself won't be affected, but clients behind it could be. The router would be a carrier of the nasty, rather than a victim itself.

Re: Lingering in the cache

Except that the router probably doesn't use glibc.

It seems to me that Linux-based SOHO routers are quite common. Presumably most of them use GNU userland, including glibc.

A better question might be "under what circumstances does my home router call getaddrinfo for an IPv6 address?". Logging, perhaps. I can see that attack surface being pretty large.

Now, all that said, the problem Kaminsky is pointing to doesn't depend on glibc being used on the system with the DNS cache - it's glibc used on any system that might receive a DNS response from said cache. So a router that uses glibc might itself be vulnerable, and any systems that use that router as a DNS server might be vulnerable.

(And it might be worth pointing out that the use of glibc on Windows systems is not unknown.)

Re: Lingering in the cache

Unless you're a Virgin Media customer with their Superhub. In which case you're probably used to rebooting the wretched thing on an almost daily basis.

I can't remember when I last had to reboot the SuperHub. Then again it has been in modem-mode since it arrived, with a router (which only routes and doesn't do DNS) behind it.

So the problem is 1) the dodgy DNS response is RFC compliant. 2) It's not easy to solve server side as caching the dodgy response for the appropriate time, is correct behaviour for all *patched* cache servers.

As far as I can see the issue is a field in the DNS response is specified as being capable of holding N-bytes, it's rarely bigger then Y bytes so it's been special cased in glibc, likely for (premature optimization / measurable performance) reasons.

The bug was about the improper handling of the transition between the fast path and the slow path, e.g. stack memory and dynamic memory.

Now take away here is accepting a long value for the DNS fields is correct behaviour as per the RFC.

So a conforming DNS Cache implementation will store this request with long fields.

An unpatched DNS Client will pull this response choke on the large field value and still overflow, the magic of which is that eventually given enough runs, you should strike it lucky and endup running into an executable address.

The way I read this is that if ALL the servers are patched, it can't because the flaw was a mismatch between allocated and used memory. The problem is that ALL of the servers have to be patched, and at least some people are normally slow to patch DNS servers since 1) they are critical infrastructure pieces, 2) historically they've been assumed to be innately more secure because they've narrowly focused at the key points. And until the LAST DNS server is patched you are still potentially vulnerable.

Re: Actually, I more confused now.

But, but, but - if my kernel isn't built with IPV6, then surely the request isn't processed but dropped? Reading the REDHAT stuff, they state disabling IVP6 doesn't mitigate it, but that is surely because their Glibc and kernels are built with IVP6?

Re: I have a retina iMac

I was being smug.

Re: I have a retina iMac

OS X does not use glibc, it uses the Darwin libc, see http://www.opensource.apple.com/source/Libc .

This is ultimately derived from the BSD project, like the rest of the core OS X (Darwin) system. (Somewhat simplified, Darwin = OS X without the GUI stuff, or alternatively, the parts of OS X which are open source since they derive from BSD.)

Re: I have a retina iMac

>outrageous money for cheap commodity hardware with an expensive badge stuck on

Still living in the 00's ? In 2016 Apple OSX laptops are not cheap commodity hardware: they are top-line hardware at a reasonably competitive price. I wouldn't put Win8 on one, but that's because Apple provides crap Windows drivers for the hardware. Running OSX, you'r paying top price for a top quality laptop.

Re: Porper use of malloc()

This is in my programs, I'm not modifying glibc. My point is that when you are accepting input, never assume that its the size you expect, so plan for it being way too large. A buffer under-flow can be safely handled by an exception in whatever piece of code is handling the data, a buffer overflow, on the other hand, could mean that the system is fully compromised.