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

[Daniel Kalchev]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20131024/463e46d7/attachment.html>