<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 22, 2013 at 11:15 PM, Paul Vixie <span dir="ltr"><<a href="mailto:paul@redbarn.org" target="_blank">paul@redbarn.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div>Haya Shulman wrote:
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
<div>
> > so if i add "first weaponized by Haya Shulman" this would
settle the<br>
> > matter?<br>
><br>
> Thank you, can you please use Amir Herzberg and Haya Shulman (I<br>
> collaborated on this attack together with my phd advisor Amir
Herzberg).<br>
<br>
</div>it shall be done.<br></blockquote><div><br></div><div style="font-family:tahoma,sans-serif">Thank you.</div></div></div></div>
</blockquote>
<br></div>
upon deeper consideration, "weaponized" is the wrong verb, unless you
have released your software. i can say "first published" if that will
serve your purpose.<div><br>
<br></div></div></blockquote><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I have implemented the code of the attack which I ran in a lab setting against Bind and Unbound, but it can't be released, since (1) it is an attack and (2) it is not automated (I adjust it manually against each target domain, and resolver, and response type, e.g., NXDOMAIN, referral or answer).</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">In any case, `first published` is fine. Can you please cite the conference version (i.e., IEEE Conference on Communications and Network Security (CNS) 2013).</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">Thank you.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><div><div style="font-family:tahoma,sans-serif">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:</div>
<div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">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.</div>
<div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">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.</div>
<div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">Both tricky
but feasible. </div><div style="font-family:tahoma,sans-serif">
Correct me if I am wrong, but I think that the cookies would not prevent
these (above) attacks. </div></div></div>
</div>
</div>
</blockquote>
<br></div>
i can't tell whether you're wrong, there's not enough detail here. if
you're able to replace the middle fragment, or perhaps replace all
fragments except the last one, then only SIG(0) or TSIG or DNSSEC could
stop you. however, my back of envelope estimate is that replacing the
middle fragment with one the same size but different content is more
than just "tricky", and replacing all-but-the-last fragment would
require many hours at 100MBit/sec, which to me places it out of
consideration as an attack worth defending against.<br></div></blockquote><div><br></div><div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">You are right that cryptographic defenses, e.g., DNSSEC, prevent the attack. </div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">Sorry for the brief description earlier, fyi, a slightly more elaborate design:</div><div class="gmail_default" style="font-family:tahoma,sans-serif">The idea is to replace a single middle fragment, e.g., given n fragments, for n>2, we replace some fragment, s.t., 1< i < n. </div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">Assume n=3 (and also assume, for simplicity, that fragments arrive in order - adjusting for the general case is straightforward). </div><div class="gmail_default" style="font-family:tahoma,sans-serif">
I want to replace fragment i=2 with a spoofed 2nd fragment. The challenge is to place the spoofed 2nd fragment in IP defragmentation cache, such that it is (1) reassembled with the first fragment, but, (2) not overwritten by the 2nd legitimate fragment. If the attacker plants a spoofed second fragment in a defragmentation cache, it will be reassembled with the 1st authentic, but then will be overwritten by the legitimate 2nd fragment that will subsequently arrive. To ensure that the spoofed second fragment is not overwritten (by the 2nd legitimate fragment), we should set its offset to some lower value (i.e., this results in a gap - that has to be filled - in the resulting reassembled packet). Then when the 3rd (authentic) fragment arrives, it is further reassembled with them (1st and spoofed 2nd). What remains to do, is to fill the missing gap in 2nd fragment.</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">So, to launch this, the attacker has to send two fragments: a spoofed 2nd fragment (which offset is lower than the offset of the authentic second fragment) before (or right after) triggering the DNS request, and after the thre fragments (authentic 1st, 3rd and spoofed 2nd) are reassembled a small fragment is sent to fill the missing bytes (in the spoofed 2nd fragment). Then the packet is ready to leave the IP defragmentation cache. </div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">So, you are right that it is more involved, but, if the fragmentation occurs at the same boundary, then it is doable. Just to clarify, when I say that there is a vulnerability, I mean, that it can be exploited in practice. As you (and others on this mailing list) mentioned, something that can be done will not necessarily be exploited, e.g., if it is too complex and the gain is not significant. </div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">The second example is an extension of the description above.</div><div class="gmail_default" style="font-family:tahoma,sans-serif">
<br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
i believe that mark andrews of ISC is going to re-release eastlake
cookies. i expect that in consideration of your fragmentation work, he
will add a 32-bit CRC covering the full message to the EDNS option that
contains the cookie. since the cookies method is something we need
anyway (for DDoS prevention), we ought to depend on it to solve for
fragmentation as well.<div><br></div></div></blockquote><div> </div><div class="gmail_default" style="font-family:tahoma,sans-serif">Is that CRC based on a cryptographic function? or is it similar to, e.g., UDP checksum?</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>
<br>
> I absolutely agree with you, deploying DNSSEC on the end hosts
would be<br>
> ideal for security.<br>
<br>
</div>wait, wait, that's not what i said. i said recursive dns should be
on-premise<br>
or on-host, not wide-area. i said nothing about end to end dnssec. what
are<br>
you specifically agreeing with?<br></blockquote><div><br></div><div style="font-family:tahoma,sans-serif">Yes you
are right, I agree with you that it is best to validate on recursive
resolver on-premise.</div></div>
</div>
</div>
</blockquote>
<br></div>
that is, again, not what i said. i want recursion, iteration, and
caching to occur on-premise or if necessary on-host. i will want this
even in the absence of globally deployed dnssec. i will also want
on-premise or if necessary on-host validation where possible, but that's
not what i was saying in the text you quoted.<div><br></div></div></blockquote><div class="gmail_default" style="font-family:tahoma,sans-serif">Ok, understood.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div style="font-family:tahoma,sans-serif">
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.</div>
</div>
</div>
</div>
</blockquote>
<br></div>
that's a controversial topic, as i expect followups to this thread to
demonstrate. i won't address it here.<div><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><br>
> I think I may have been misinterpreted. I believe cryptography is
important<br>
> and efforts should be invested in deployment of DNSSEC. One of the
goals of<br>
> our work on DNS was to motivate adoption of DNSSEC.<br>
<br>
</div>that's great to hear.<br>
</blockquote></div>
</div>
</div>
</blockquote>
<br></div>
a side by side reading of your earlier draft
(<a href="http://arxiv.org/pdf/1205.4011.pdf" target="_blank">http://arxiv.org/pdf/1205.4011.pdf</a>) and your current draft:<br>
<br>
<span><a href="https://0a94266f-a-62cb3a1a-s-sites.googlegroups.com/site/hayashulman/files/fragmentation-poisoning.pdf?attachauth=ANoY7cpB1yJsBXMWL0_spxDjUMV9m5G_TjI98UgJE6OtoP98H-WrlRJ2AyJVhajdZ5za2vjZ14twuMHuB7NUcRW_EYv36scybuofLgPOwoU2Rvs7zpSnm_Qj3jA3noSc3ibX9b9_7tncZJdGca0FLY8SOrzMTY_O5bd0NPcwBXtDx9vtCjbRisMFf48MiOYFNO-66BY3iyGa584pJ0Sy2vYfI5ZKKCmvJhJsmY96N4XChK5cGgky8eg%3D&attredirects=0" target="_blank">https://0a94266f-a-62cb3a1a-s-sites.googlegroups.com/site/hayashulman/files/fragmentation-poisoning.pdf?attachauth=ANoY7cpB1yJsBXMWL0_spxDjUMV9m5G_TjI98UgJE6OtoP98H-WrlRJ2AyJVhajdZ5za2vjZ14twuMHuB7NUcRW_EYv36scybuofLgPOwoU2Rvs7zpSnm_Qj3jA3noSc3ibX9b9_7tncZJdGca0FLY8SOrzMTY_O5bd0NPcwBXtDx9vtCjbRisMFf48MiOYFNO-66BY3iyGa584pJ0Sy2vYfI5ZKKCmvJhJsmY96N4XChK5cGgky8eg%3D&attredirects=0</a>
<br>
<br>
...shows a remarkably different attitude toward dnssec. what led to your
reconsideration?<span><font color="#888888"><br>
<br></font></span></span></div></blockquote><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Your observation is correct. Initially it seemed that large responses were a consequence of DNSSEC. But, then we found other techniques to cause fragmentation, not related to DNSSEC, like spoofed ICMP fragmentation needed (reduces the MTU beyond 1.5KB - and removes the requirement of large responses), and malicious domains (created by the attacker), with large responses. This made it clear that the attacks were not an artifact of DNSSEC.</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><div class="gmail_default">On the other hand, DNSSEC prevents these (and other known and future, unforeseen) attacks against DNS.</div>
<div class="gmail_default"><br></div></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I also found it very easy to deploy DNSSEC on resolvers, and zones. Many people invested a lot of efforts in it, and there are a number of elaborate tutorials available online, and automatic scripts (e.g., keys generation, automatic zone signing procedures).</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I faced some challenges related to interoperability, e.g., the network that we ran the attacks on, blocks fragments (in the FW), and we had to explicitly ask to allow fragments to our resolver host. </div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"> Of course, these (and/or other) challenges are not specifically an issue of DNSSEC, but a general challenge of deploying new mechanisms in the Internet. </div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span><span><font color="#888888">
vixie<br>
</font></span></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><p style="margin:0cm 0cm 0.0001pt"><font color="#000000" face="Calibri, sans-serif"><span style="font-size:14.545454025268555px">Best Regards,</span></font></p>
<p style="margin:0cm 0cm 0.0001pt"><font color="#000000" face="Calibri, sans-serif"><span style="font-size:14.545454025268555px">Haya Shulman</span></font></p><p style="margin:0cm 0cm 0.0001pt"><font color="#000000" face="Calibri, sans-serif"><span style="font-size:14.545454025268555px">Technische Universität Darmstadt</span></font></p>
<p style="margin:0cm 0cm 0.0001pt"><font color="#000000" face="Calibri, sans-serif"><span style="font-size:14.545454025268555px">FB Informatik/EC SPRIDE</span></font></p><p style="margin:0cm 0cm 0.0001pt"><font color="#000000" face="Calibri, sans-serif"><span style="font-size:14.545454025268555px">Mornewegstr. 30</span></font></p>
<p style="margin:0cm 0cm 0.0001pt"><font color="#000000" face="Calibri, sans-serif"><span style="font-size:14.545454025268555px">64293 Darmstadt</span></font></p><p style="margin:0cm 0cm 0.0001pt"><font color="#000000" face="Calibri, sans-serif"><span style="font-size:14.545454025268555px">Tel. <a href="tel:%2B49%206151%2016-75540" value="+4961511675540" target="_blank">+49 6151 16-75540</a></span></font></p>
<p style="margin:0cm 0cm 0.0001pt"><font color="#000000" face="Calibri, sans-serif"><span style="font-size:14.545454025268555px"><a href="http://www.ec-spride.de" target="_blank">www.ec-spride.de</a></span></font></p></div>
</div></div>