[dns-operations] summary of recent vulnerabilities in DNS security.

[Vernon Schryver]

> From: Haya Shulman <haya.shulman at gmail.com>

> > My problem with your findings is that your are grossly overstating
> > their significance. None of them will ever be seen in the wild. As
> > As http://link.springer.com/chapter/10.1007/978-3-642-33167-1_16 and
> > as I've said, showing the inevitiable weakness of port randomization
> > is good.
>
> We found and described the vulnerability and showed how to apply it against
> standard and patched resolvers. Can you please clarify in what way our
> results `grossly overstate` significance?

Your claims that your issues are a significant security problem are
grossly exaggerated, because they will never be seen in the wild.

> Your second argument is not precise, we, and recently others, showed these
> attacks to be practical. Could you please explain why you are certain that
> the attacks do not pose a practical risk?

The existence of a vulnerability does not imply that it will be used.
Bad guys only use profitable attacks, whether the profit is mischief
or money.  Exploiting your vulernabilities is too hard (less profitable)
compared to other vulnerabilities.

> I'm sorry, but I think the mention of DNSSEC in your paper exists only
> > because others forced it. I'm forced to that belief by various things
> > including your refusal admit the obvious about relative priorities and
> > by statements like that sentence above that suggests that fixing port
> > randomization could be easier than deploying DNSSEC in any except quite
> > exceptional cases.
>
> This conspiracy theory is intriguing...

It would be conspiracy thinking if I claimed you worked with others
to (not) do something.  I'm only extrapolating from your consistent
evasions of my question about the relative importance of port
randomization and DNSSEC.

I notice that besides not answering the priority question, you also
did not say where we can read your paper to see whether you mention
DNSSEC only as a coerced afterthought.

However, I've been asking and you've been evading the wrong question.
Whether DNSSEC work should be done before or after randomizing ports
is moot, because I think everyone who might randomize DNS ports while
it matters has already done so.  The major DNS implementors have also
done most of what they can for DNSSEC.  That various junk CPE forwarders,
proxies, and resolvers doesn't randomize won't be changed while it
matters.  Those vendors and their ISP customers aren't listening and
care about neither DNSSEC nor port randomization.  The only people who
might act on your issues are DNS user who cannot do anything about
port randomization but could deploy DNSSEC.

And that brings me to something bad.  Your are giving people an
excuse to continue not deploying DNSSEC.  By not admitting that
DNSSEC is more important than randomizing ports, you are encouraging
people to continue waiting for others to fix the problem.  They are
often the same people who are waiting for everyone else to comply
with BCP 38.  Note that BCP 38 violations would probably figure in
any real exploit of your issues.


    .......

} From: Haya Shulman <haya.shulman at gmail.com>

} This year there were a number of injection attacks against TCP exploiting
} port randomisation algorithms recommended in [RFC6056]. Once port is known,
} TCP sequence number does not pose a significant challenge (although it is
} 32 bits, it is incremented sequentially within the connection and there are
} techniques to predict it) Port randomisation would prevent injections into
} TCP.

} For instance, name server pinning, identifying victim instances on cloud,
} derandomisation of communication over TOR. There are limitations to these
} attacks, but IMHO even if there are only few networks to which these
} attacks apply - these are still attacls. Port randomisation would prevent
} these attacks of course since the attacker would not know which .
} Port randomisation was also proposed as a countermeasure against DoS
} attacks (e.g., see here Denial of service protection with beaver).
}
} Please clarify why you think that port randomisation cannot prevent the
} attacks described above.

That is more wrong that right.  Port randomization is worth doing, but
it is a minor issue among TCP application security issues.  Port
randomization helps little because the range of ephemeral ports is
tiny and so cannot contain much entropy.  Attacks based on predicting
TCP sequence numbers require either being able to see TCP sequence
numbers, in which case you can also see port numbers, or brute force.
If you're flooding the target hoping to it a TCP window, you need only
increase your flood to hit a random port.

} Bernstein identified preditable ports to be vulnerable long ago, it is
} surprising to me, that after so many years, the community is still not
} convinced that port randomisation is signfiicant.

Outside the Steve Gibson School of Internet Security, "significance"
is relative.  There will always be an infinite number of vulnerabilities.
Competent defenses don't elevate a convenient issue like raw sockets
above all others.  To the extent that the punters paid attention Steve
Gibson's campaign against Windows XP because of raw sockets, he harmed
them and the Internet in general, because XP was less insecure than
previous versions of Windows.

} Furthermore, if port randomisation is not an issue why standardise
} [RFC6056]? Why set up DNS checkers? If current port randomisation
} algorithms are vulnerable - why not fix?

That's a straw man.  No one has said that ports should not be random.
It was an unfortunate oversight that RFC 1948 did not recommend random
emphemeral ports.  If RFC 1948 had mentioned port numbers it would
have concluded:

   Good sequence numbers AND PORT NUBMERS are not a replacement
   for cryptographic authentication.  At best, they're a palliative
   measure.
     (capitalized words added to actual RFC 1948 text).


Vernon Schryver    vjs at rhyolite.com