<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 23.10.13 22:17, Haya Shulman wrote:<br>
</div>
<blockquote
cite="mid:CAKaJYMAQPY2nnY26XTDsymNzuHyzo0CZ567pMr6VODdXKw8CHQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">Sorry for the brief description
earlier, fyi, a slightly more elaborate design:
<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. <br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
This is not an attack on DNS, but an attack on IP reassembly
technology. Which might work or not work depending on how the
particular TCP/IP stack functions.<br>
This attack affects any IP based protocol and therefore should in no
case be labeled "DNS vulnerability".<br>
<br>
This is essentially an IP packet modification vulnerability and in
order to do these, you don't even need fragmentation. This might
happen even due to malfunctioning network adapter or other network
device, not necessarily an "attack". One of the reasons for DNSSEC
existence is to prevent processing of "damaged" DNS data, with
malicious origin or not.<br>
<br>
If you are concerned with improperly assembled IP packets, the DNS
community is the wrong place to ask for a fix. The DNS community can
only make sure "their" protocol takes care of such issues, and
issues like this are totally addressed by technologies such as
DNSSEC, TSIG etc. But the fundamental "fix" for this issue has to
happen in the TCP/IP stack.<br>
<br>
<blockquote
cite="mid:CAKaJYMAQPY2nnY26XTDsymNzuHyzo0CZ567pMr6VODdXKw8CHQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">a side by side reading of your
earlier draft (<a moz-do-not-send="true"
href="http://arxiv.org/pdf/1205.4011.pdf" target="_blank">http://arxiv.org/pdf/1205.4011.pdf</a>)
and your current draft:<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">
<br>
<span><a moz-do-not-send="true"
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>
</div>
</div>
</div>
</blockquote>
<br>
No technology, including DNSSEC claims to protect against future
unforeseen attacks. DNSSEC in this case simply ignores packets that
have invalid cryptographic signatures, for whatever reason. There
might be other attacks on DNS that DNSSEC might not be able to
defend against.<br>
<br>
Daniel<br>
</body>
</html>