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

[Haya Shulman]

>
> That claim against having "[injected] spoofed content into the DNS
> response (despite the use of Eastlake cookies for protection)" is false
> unless that attack was against DNS clients and servers using DNS
> cookies, and not merely the cookies described in
> https://tools.ietf.org/html/draft-eastlake-dnsext-cookies-03
> but cookies in an as-yet unpublished proposal with a payload checksum.
> Note that I thought that there are no available implementations even
> of original flavor cookies.



You may have missed the beginning of that discussion... Paul Vixie already
suggested to add a CRC to protect against our fragmentation attacks, as
well as the new attack idea that I proposed earlier in this thread, fyi:


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.



In any case, it is great that you also agree that the published proposal
may be vulnerable and propose to use checksum to prevent those attacks.


On Sat, Oct 26, 2013 at 12:12 PM, Haya Shulman <haya.shulman at gmail.com>wrote:

>  No number of hosts sending packets can exceed 25,000 500 Byte packets
>> to a single 100 MHz 802.3 host. In fact, 802.3 preamble, headers, CRC,
>> and IFG limit the 500 Byte packet rate to below 25K pps. However,
>> multiple attacking hosts could cause excessive link-layer contention
>> (nothing to do with host or host network interface "interrupts" or
>> "buffers") and so packet losses in either or both directions for
>> legitimate DNS traffic and so the reported effects.
>
>
>
>> Without data such as packet counts from standard tools such as `netstat`,
>> my bet is what I said before, that the application fell behind, its socket
>> buffer overflowed, and the results were as seen. However, I would not
>> bet too much, because there are many other places where the DNS requests
>> or responses could have been lost including:
>> - intentional rate limiting in the DNS server, perhaps even RRL
>> - intentional rate limiting in the kernel such as iptables
>> - intentional rate limiting in a bridge ("hub") in the path
>> - unintentional link layer rate limiting due to contention for
>> bridge buffers or wires. At full speed from the attacking systems,
>> unrelated cross traffic through hubs in the path or on the wires
>> to DNS server would cause packet losses including losses of valid
>>      answers and so timeouts and so the observed effect.
>
>
> No iptables rules were set; no RRL was applied (when sending bursts to
> incorrect/closed port - legitimate responses arrived ok).
>
> There are these measurments that studied loss due to traffic volume, and
> they found that Kernel loss occurs at above 100-150 Kpps (packets per
> second), with 64 byte packets. One of these works, in addition to measuring
> loss in kernel, also measured performance of snort under heavy load, and
> found loss could occur above 100KB.
> http://www.sciencedirect.com/science/article/pii/S143484110600063X
>  http://www.sciencedirect.com/science/article/pii/S1084804509001040
>
> Two significant differences between our and their setting is that they
> used only a single host that generated the traffic, and the traffic
> consisted of 64  Byte packets (we used 500Byte packets).
> In any case, I am curious as to wether the loss occured in DNS software
> and if increasing the buffers in DNS software can mitigate the problem
> (I'll run it again to confirm).
> Thanks.
>
>
> --
>
> 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
>



-- 

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