If you’re not worried about your DNS security then you don’t understand the problem
The “Golem” bug underscores the complex interdependencies associated with DNS.
Stone and wooden bridge, castle of Harcourt (France, Normandy) (source: Wikimedia Commons)
I’ve long commented that DNS is something nobody cares about until it stops working. Like a broken record, I frequently ruminate that I see all kinds of organizations, from government and law enforcement agencies, to highly tech-savvy startups, to financial platforms and unicorns, put huge resources and diligence into security, monitoring and disaster recovery. And yet, when you peer under the covers you realize the entire operation is being held up by a domain running on a couple of crappy name servers that nobody is paying any attention to. Alternatively, the entire thing can come crashing down the next time an intern in the mail room forwards a Domain Registry of America “invoice” over to accounts payable …
Get ready for another glibsploit
To wit, CVE-2015-7547 was recently discovered in parallel research efforts by Fermin J. Serna and Kevin Stadmeyer of Google, and Florian Weimer and Carlos O’Donell of Red Hat. This pervasive bug, affecting glibc from version 2.9 and beyond across all linux distributions, is so serious (it theoretically allows for Remote Code Execution) that it should incite a full-on panic reminiscent of Heartbleed or Poodle. Dan Kaminsky called it “unusually bad.” But the response to me seems muted, with reactions of fleeting curiosity, as in “oh my, that’s awful.” But I see no palpable anxiety, no “all hands on deck,” no “all leave cancelled,” no “put on the coffee and buy Jolt” until the situation is fully diagnosed and mitigated.
Learn faster. Dig deeper. See farther.
Perhaps some could attribute that to there being no known exploit in the wild for it, yet. However my opinion is that this ambivalence is because it’s a DNS issue and a lot of people, aside from DNS geeks, think that DNS is somebody else’s problem. In my book, Managing Mission-Critical Domains and DNS, I argue that it is never somebody else’s problem; or, more accurately, it is never not your problem. Even if you outsource your DNS to a vendor, you still need to manage that external vendor – or vendors – and you need to have coherent internal policies that structure all aspects of your DNS and domain portfolio.
Further, even if you outsource (and, of course, for some aspects of your naming infrastructure you must outsource, if only to use a third-party registrar to register your domains), even if you are “bulletproof,” some third-party vendors may be vulnerable, which then renders you bullet-prone.
These types of security issues underscore the complex interdependencies we risk taking for granted on the Internet, and nowhere is this more true than within the DNS. The bug itself is not straightforward and obvious; it is subtle. It’s not the name server daemons themselves that are vulnerable. Rather, it’s the libraries that the applications use (which are the name servers’ clients) when they call getaddrinfo().
Attack vectors and wishful thinking to avoid
Attack vectors could come via an attacker-controlled domain, an attacker-controlled name server or man-in-the-middle attack (MITM) attack. The vulnerable servers and Internet hosts would be anything that houses applications that make use of getaddrinfo(). Those applications could be used to trigger the vulnerability, and the remote code execution would occur on the client server, not on the resolver name server.
“We’re OK because we outsource all our DNS” is a fallacy. This isn’t about authoritative name servers per se. Those generally answer queries directly from their own internal representation of the zone data of the domains they are authoritative for.
“We’re OK because our glibc is < 2.9” is not a viable stance either because you should have upgraded already. There are other earlier glibc issues, such as CVE-2015-0235 a.k.a “Ghost.”
“We’re OK because we use external resolvers” is also a fallacy because you have no control over those external resolvers, and if they’re vulnerable (in this case defined as not suitably filtering hostile payloads from the queries they are sending back to you) and your local applications are using them for resolution, it’s your stack that gets smashed, not theirs.
“We’re OK because we use our own resolvers” is another fallacy because, again, this isn’t so much about the resolvers. It’s about the local glibc library and any applications that will use it. The resolvers could help mitigate if they can detect attack packets, but it’s no substitution for upgrading glibc.
The above also applies if you think you’re OK because you use bind, which doesn’t call getaddrinfo(), or powerdns, the latter of which analyzed their susceptibility and surmised it would be difficult to exploit but added further lua hooks to address it. If you’re running one of them locally, then even though your local recursor would be relatively safe, any of your other hosts that use it as a resolver wouldn’t be because they would use getaddrinfo() in their local vulnerable glibc libraries to query them.
Same again for OpenDNS, which disclosed in response to the announcement of this vulnerability that they, too, do not use getaddrinfo(), and they also claimed to protect clients from malicious payloads. Yes, they do do that, in that they drop any malformed response packets—as would any well configured resolver—but that doesn’t make you safe if you haven’t patched your own glibc. A hostile payload could still be delivered via a well-formed packet.
“We’re OK because we’ve upgraded glibc across our entire network” is the correct approach.
Lessons we can learn from the Golem
This bug, which I’ve learned has been christened “Golem,” is instructive because it exemplifies how an awareness of your DNS architecture—whether it is in-house, outsourced, or a combination—that includes your authoritative DNS, your resolvers, your forwarders, and everything that does DNS lookups within its scope, is required tribal knowledge within any organization.
Too often it isn’t, and that’s why I’m writing Managing Mission-Critical Domains and DNS, which will be ready soon. Promise.