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

[Vernon Schryver]

> From: Haya Shulman <haya.shulman at gmail.com>

> > 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.

I do not understand why that paragraph was quoted, because Haya
Shulman's following paragraph is almost unrelated to it.  The main
point of the preceding paragraph seems to be

   DNSSEC protects DNS data intentional and accidential data change
   or corruption in the lower layers.  Fixes for other application
   protocols vulnerable to fragmentation attacks are off topic here.

> IP does not, and was not designed to, guarantee security - only best effort
> end-to-end delivery. The discussion was if Eastlake cookies can prevent the
> attacks: the example I showed was a legitimate way to apply IP
> fragmentation (which is a feature of IP - it is not a bug) to foil the
> protection offered by Eastlate cookies and to inject spoofed content into
> the DNS response (despite the use of Eastlake cookies for protection). 

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.

I do not understand how a blind attack against DNS cookies checksums
would work.  That makes me wonder whether these fragmentation attacks
are blind.  IP fragementation or TCP segment assembly attacks in which
the attacker can see all of the traffic are, to understate the case,
much less interesting.

If these attacks are blind, how do they fix the UDP checksum?  This
is somewhat relevant, because there are far easier attacks than IP
fragmentation for an attacker who can see DNS traffic.  It is only
somewhat relevant, because the answer is still DNSSEC.


>                                                                    This
> should be of interest to DNS community, unless you argue that the DNS
> community should rely on IP layer for security of DNS.

No one said anything like "[relying] on IP layer for security of DNS."
As Paul Vixie repeatedly wrote, cookies is need to protect against 
reflection attacks.  On the other hand, DNSSEC is the source of DNS
data security.  Maybe that's why it's called DNSSEC.

 .....


} From: Haya Shulman <haya.shulman at gmail.com>

} 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

I see little relevant to current PC hardware or software in that
abstract of a 7 year old paper.  It does tend to contradict Haya
Shulman's apparently unsupported guesses about the causes of the
packet losses she observed.

} http://www.sciencedirect.com/science/article/pii/S1084804509001040

That paper is not as ancient, but it is even more irrelevant.


} 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).

I do not understand why spend that effort is worthwhile.  If as I
suspect, increasing DNS forwarder socket buffer size tends to
mitigate the attack, we'll know something we already knew, that the
attack is less likely to work everywhere.  However, no DNS server
software maintainer would consider changing socket buffer sizes
based this issue.  The fix for DNS insecurity is DNSSEC.

This paper of Haya Shulman reports that by DNS request flooding of a
recursive, an attacker might determine the DNS client port numbers
used by the server.  That might be interesting by contradicting claims
DNS forwarding is secure because no one can know those port numbers.
(Never mind that the first I've heard of such very weak security claims
are in Haya Shulman's papers.)  The reasonable conclusion to this 
report is
  "Deploy DNSSEC because DNS without DNSSEC is insecure."

The paper also contained an explanation of the effect that is
unsupported by measurements, tests, or code reading and simply
wrong.  That explanation is also irrelevant to the point and
reasonable conclusion of the paper.  The right way to fix the paper
is to remove the relevant, unsupported explanation.


Vernon Schryver    vjs at rhyolite.com