DNS spoofing vulnerability
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
Men & Mice
More information about the hlfs-dev