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

[Haya Shulman]

On Mon, Oct 21, 2013 at 1:42 PM, P Vixie <vixie at fsi.io> wrote:

> On Tuesday, October 22, 2013 19:47:34 Haya Shulman wrote:
> > 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.
> >
> > updated papers are available.
> > sites.google.com/site/hayashulman/publications
>
> so noted.
>
> > > 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).
>
> it shall be done.
>

Thank you.

>
> > I agree with you that there are other vulnerabilities, which may be
> easier
> > for attackers to exploit, that have to be addressed.
>
> do you also agree with me that they would have to be addressed first, since
> they represent greater risks, and do you also agree that if the other known
> problems are addressed (for example, using eastlake cookies) that your
> fragmentation related vulnerabilities will have been resolved by
> side-effect?
>
> I agree with you that plenty other concerns have to be addressed. I also
agree that full and correct DNSSEC deployment would prevent the attacks.

Eastlake cookies is a very neat proposal. In contrast to other
challenge-response mechanisms, which reuse existing fields for security
(while those fields were originally designed for a different purpose),
e.g., source ports, Eastlake's proposal uses the EDNS to add randomness in
order to authenticate communication between resolver and name server. So,
you are right, it does prevent many attacks, but, it does not prevent all
the attacks, particularly those that exploit fragmentation. For instance:

1. what about an IP packet that is fragmented into three fragments, such
that the EDNS OPT RR is in the third fragment? By replacing the second
fragment, the attacker can inject malicious content.

2. another example also involves IP fragmentation, however in this scenario
the second fragment can be of any size, e.g., a single byte. The attacker
overwrites the transport layer port of the first fragment, e.g., to its own
port and intercepts the packet (along with the cookie); replaces the DNS
records and forwards the resulting response to the resolver.

Both tricky but feasible.
Correct me if I am wrong, but I think that the cookies would not prevent
these (above) attacks.


> > ... 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.
>
> wait, wait, that's not what i said. i said recursive dns should be
> on-premise
> or on-host, not wide-area. i said nothing about end to end dnssec. what are
> you specifically agreeing with?
>

Yes you are right, I agree with you that it is best to validate on
recursive resolver on-premise. But, I also wanted to add, that I think best
to validate on the end host; this would also prevent attacks by attackers
that are on the same network with the client, e.g., wireless networks or
networks of ISPs.

>
> > 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.
>
> this is nonsequitur. it's as if i'd asserted A and you'd said "B is
> complicated".
>
> > 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.
>
> that's great to hear.
>
> 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/1f4fdff9/attachment.html>