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

[Paul Vixie]

note, i am using <http://arxiv.org/pdf/1205.4011.pdf> as my reference to
haya shulman's fragmentation related attack. i found this by googling
for "fragmentation considered poisonous" which is the string i used to
reference haya's work in my circleid blog post.

Haya Shulman wrote:
>  
> ---
>
>     thanks for clarifying that. i cannot credit your work in the
>     section of
>     my article where i wrote about fragmentation, because you were not the
>     discoverer.
>
>
> @/Paul Vixie/ 
> BTW, when we shared this attack with you, after some correspondence
> where we explained the details, you wrote to us admiting that it was
> different from the vulnerability that Florian discussed with you (I
> can forward that email if you prefer). 
> But, irrespectively, even if it was suggested that fragmentation poses
> a vulnerability (and indeed it has a long history of attacks) - there
> is a difference between suggesting something and actually doing it
> (there are different pieces that need to be put together). Had there
> been a source where this attack was described, I would have of course
> cited it, this is the only ethical thing to do.
> As I wrote in an earlier email, port randomisation vulnerability was
> identified long ago by Bernstein, and yet Paul Vixie (justly) credits
> Dan Kaminsky for putting the pieces together. Of course Dan deserves
> the credit - putting it all together requires research and work. So, I
> look forward to seeing this fixed.

so if i add "first weaponized by Haya Shulman" this would settle the matter?

as to bernstein, i credit him with source port randomization but not
with spoofed-source guessing attack which was first told to me by peter
shipley in 1994 when BIND's TXID generator was a simple increment. i
added simplistic randomization, against which theo de raadt weaponized a
TXID predictor. the randomized TXID generator in later BIND 4 and all of
BIND 8 was theo de raadt's work. kaminsky's innovation was not to
weaponize it, we all knew that a sustained flow at 100Mbit/sec would
yield a correct guess in a matter of ten minutes or so. kaminsky's
innovation was to include poison NS RR's which would overwrite the cache
(coming as they appeared to come, from the apex of the zone, which is
considered more credible than the delegation from the ancestor).
bernstein's source port randomization was argued at the time only by
cache poisoning of single records, and on that basis, the cost/benefit
was wrong -- as witness the problems caused by source port randomization
for stateful firewalls and NATs. only kaminsky's NS RR poisoning raised
the cost of cache poisoning to the point where source port randomization
was economically justified.
>
>     Disclosing such potential vulnerabilities remains valuable work, but I
>     think careful consideration needs to be applied to the engineering
>     economics of the best operational-world mitigation approaches.
>
>
> ---
>
> @/Keith Mitchell/
> I do not advocate to deploy these or other countermeasures. ...

yes, you are, and you have been. when you worked before publication to
pre-notify implementors and operators about your problem, it was on the
basis of your stated expectation that this was a big problem and would
require an immediate fix. you've been challenged on that assertion.
given a finite "fix the dns's security problems" global aggregate
budget, your fragmentation attack is nowhere near the top of the
priority list. so while your observations are accurate, there's a lot
more operational security to be had by fixing other things which will be
easier. for example, source port randomization is nowhere near
universal, and nonrandomizing caching resolvers are a greater danger to
us all than your fragmentation related attack. furthermore the outdated
CPE's which de-randomize source ports are a bigger problem than your
fragmentation related attack, and they MUST be fixed before your
fragmentation related attack will be tractable. and of course, DNSSEC is
not universally deployed, which poses a far greater risk to us all than
your fragmentation related attack, since any on-path attacker has
complete control of the dns cache today.

i challenged you privately, and i now do so publicly, to state why your
fragmentation related attack was a greater menace to the internet than
other known problems in DNS such as: lack of universal SPR,
derandomizing NAT boxes, or lack of DNSSEC. your weaponization in 2012
of the fragmentation related attack first told to me in 2008 by florian
weimer did not warrant a CERT advisory, nor private circulation of the
vulnerabillity, because far from needing to be fixed urgently, it is
unlikely to ever be fixed at all, because as stated, there are bigger
problems which deserve priority attention, which in their aggregate will
obviate your attack through indirect means.

>
> Which brings me to the topic of resolver-behind-upstream attacks which
> were not commented upon.
> As you know, one of the recommendations of experts and Internet
> operators, following Kaminsky attack, was `either deploy patches or
> configure your resolver to use a secure upstream forwarder`, e.g.,
> OpenDNS was typically recommended. The security is established since
> the resolver is hidden from the Internet and sends its requests only
> via its upstream forwarder.
> This configuration is still believed to be secure and is recommended
> by experts.

well, if i'm an expert, then not all experts think that outsourcing
recursive dns (to opendns, or to google, or to one's ISP) is secure or
reasonable. i want the record to be clear on that point -- people should
run their own recursive dns, on-prem or in-laptop. i'll make an
exception for smart phones, who should be using their provider's
recursive DNS, and not google's or opendns. your observations about
fragmentation related vulnerabilities in the use of wide area recursive
dns are welcome, since we need more nails for the coffin that wide area
recursive dns belongs in. but it was already a bad idea even before your
fragmentation related observations were published.

vixie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20131022/2d33f2cb/attachment.html>