DNS spoofing vulnerability

Chris Buxton cbuxton at menandmice.com
Mon Jul 14 11:00:54 PDT 2008

On Jul 14, 2008, at 9:32 AM, marty wrote:

>> djbdns and PowerDNS are not vulnerable to this new attack vector
>> because they don't hold open an outbound source port for queries.
> DUH? Those authors realized the implications years ago, and
> took precautions that render them invulnerable today. Just
> because others ignored logic does not make this 'new'.

True, I agree, holding open the source port seems like an awfully  
silly self-inflicted wound. But we're seeing problems from the fix,  
too, in the form of too many file descriptors (open ports), as ports  
are held open waiting for a reply. Systems that get thousands or tens  
of thousands of recursive queries per second are having serious  
problems with the new BIND and MS DNS releases.

I teach DNS theory. I've told my classes for years that BIND's  
behavior of holding open a single source port for queries seemed like  
a bad idea. And now we see why. It's unfortunate that the majority of  
the Internet uses the BIND name server for resolving name service, and  
not djbdns or PowerDNS. (In the case of djbdns, Professor Bernstein's  
general crackpot-seeming nature might have something to do with this.)

But the glibc stub resolver is based on the BIND stub resolver code,  
and therefore I started this thread asking if this was going to be a  
problem for HLFS.

>> The QA manager for CentOS, a friend of mine, told me that glibc is
>> also vulnerable.
> But he was referring to their glibc, not ours;O

That is apparently true. And I am very happy to see evidence that the  
problem in glibc has already been addressed for HLFS. I don't think we  
can say for sure until the attack vector has been disclosed and any  
actual problem with glibc has been discussed publicly, but until that  
time, I will rest easier.

> These 'revelations' only show the impact of rumors.

Believe me, I was of the same opinion as you until Friday. I was sure  
that this was just the same old thing as before, and that Kaminsky was  
just grandstanding for the masses. Then the folks at ISC started  
contacting me in private and telling me a different story.

> This IS the same old thing despite the newer codebase which
> is affected, which adds more twists. Just because somebody
> cracked a box in a lab does NOT constitute a good reason for
> spreading alarm and panic.

I think we will have to disagree on this until Mr. Kaminsky makes his  
exploit public. I don't have the facts of the exploit, only the  
evidence of some very concerned experts who've signed the NDA and seen  
the attack mechanism.

> I don't use Microsoft products, or Distributions as servers.

Here we are in agreement.

> I don't even have a cache which can be poisoned.

You're using a resolving name server somewhere. That resolving name  
server almost certainly has a cache.

> I don't provide recursive DNS to the public.

Does it provide recursive DNS service to anyone? To you? If so, your  
recursion restriction does not protect you.

> My DNS server
> will reject out of zone queries.

The attack isn't based on queries, but rather on forged responses. I'm  
still having a hard time understanding what the attack vector could  
be, but people I trust who have been told (and can't tell me) have  
said that any resolving name server based on BIND from before the  
updates last week is vulnerable to a very fast, very effective attack,  
no matter how well-secured. The only protections are:

- Disable recursion entirely. Forwarding is not a solution.
- Upgrade to a patched version of BIND or MS DNS.
- Don't use MS DNS or BIND for your recursion servers.

> I don't need dnssec.

Please explain your rationale for this statement.

> Source ports are randomized by design in my software.

If you use BIND as a resolving name server, the versions available  
before last Tuesday did not change their randomized ports between  

> Everything is behind firewalls on Nat. And I use HLFS.

None of that will help you in the slightest if you run a resolving  
name server based on BIND.

> You are crying wolf again. Take a Valium.

I am not crying wolf unnecessarily. (And why do you use the word  

I said at the beginning of this thread that I had heard that stub  
resolvers were vulnerable also. If the HLFS version of glibc's stub  
resolver is already using random source ports, then that's great. End  
of story. The HLFS book does not include instructions to set up a DNS  

Then you asserted that this is the same old DNS spoofing attack  
(message ID guessing + port guessing) that we've seen for years, and I  
responded in an attempt to set the record straight. I apologize if my  
response was too verbose for you. However, as a DNS professional, I am  

Chris Buxton
Professional Services
Men & Mice

More information about the hlfs-dev mailing list