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

[Haya Shulman]

On Tue, Oct 22, 2013 at 6:20 PM, Paul Vixie <paul at redbarn.org> wrote:

> 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.
>
> In the first message in this thread I referred to my site, where all
updated papers are available.
sites.google.com/site/hayashulman/publications

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?
>

Thank you, can you please use Amir Herzberg and Haya Shulman (I
collaborated on this attack together with my phd advisor Amir Herzberg).

>
> 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.
>

Ok, thank you for the clarification.

>
> 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 appreciate your comments on this issue. The reason for this was that we
were concerned with the legal implications of a disclosure of such attacks,
and we did not want to publish them before coordinating careful disclosure.
We wanted to make sure all relevant parties were notified. After discussing
this with the EFF, we understood that since we tried to disclose and notify
the impacted parties, we were `ok`, and so we sent the work for publication
at a security conference (which was accepted and will appear soon).

I agree with you that there are other vulnerabilities, which may be easier
for attackers to exploit, that have to be addressed.

>
> 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.
>

I absolutely agree with you, deploying DNSSEC on the end hosts would be
ideal for security.
There are obstacles to this though, that may have to be addressed in some
networks, including support by applications, interoperability problems, and
even other issues that may discourage clients from validating, e.g., as you
published, ISPs mangling NXDOMAIN responses.
I think I may have been misinterpreted. I believe cryptography is important
and efforts should be invested in deployment of DNSSEC. One of the goals of
our work on DNS was to motivate adoption of DNSSEC.


>
> vixie
>



-- 

Haya Shulman

Technische Universität Darmstadt****

FB Informatik/EC SPRIDE****

Mornewegstr. 30****

64293 Darmstadt****

Tel. +49 6151 16-75540****

www.ec-spride.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20131022/9d9af1f6/attachment.html>