On 23.10.13 22:17, Haya Shulman wrote:
Sorry for the brief description earlier, fyi, a slightly more
elaborate design:
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.
Assume n=3 (and also assume, for simplicity, that fragments arrive in
order - adjusting for the general case is straightforward).
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.
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.
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.
This attack affects any IP based protocol and therefore should in no
case be labeled "DNS vulnerability".
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.
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.
a side by side reading of your earlier draft
(http://arxiv.org/pdf/1205.4011.pdf) and your current draft:
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
...shows a remarkably different attitude toward dnssec. what led
to your reconsideration?
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.
On the other hand, DNSSEC prevents these (and other known and future,
unforeseen) attacks against DNS.
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.
Daniel
_______________________________________________
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
