On Tue, Oct 22, 2013 at 11:15 PM, Paul Vixie <p...@redbarn.org> wrote:
> Haya Shulman wrote: > > > >> > > 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. > > > 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. > > > 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). 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). Thank you. 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. > > > 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. > You are right that cryptographic defenses, e.g., DNSSEC, prevent the attack. 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. 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. The second example is an extension of the description above. > 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. > > Is that CRC based on a cryptographic function? or is it similar to, e.g., UDP checksum? > > > >> > 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. > > > 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. > > Ok, understood. > > 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. > > > that's a controversial topic, as i expect followups to this thread to > demonstrate. i won't address it here. > > > >> > 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. >> > > 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. 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). 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. 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. vixie > -- Best Regards, Haya Shulman Technische Universität Darmstadt FB Informatik/EC SPRIDE Mornewegstr. 30 64293 Darmstadt Tel. +49 6151 16-75540 www.ec-spride.de
_______________________________________________ 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