[dns-operations] DNS Attack over UDP fragmentation

[Yasuhiro Orange Morishita / 森下泰宏]

Aaron-san, Haya-san, and folks,

I've found the following RFC, it's published in 2007.

  RFC 4963 - IPv4 Reassembly Errors at High Data Rates
  <http://tools.ietf.org/html/rfc4963>

And I've cited "Security Considerations" of this RFC as below:

BTW, When the RFC was I-D, it's titled "IPv4 Fragmentation Considered
Very Harmful".

  <http://tools.ietf.org/html/draft-heffner-frag-harmful-03>

So, we should have been discussing this issue before DNSSEC deployment.

-- Orange

---
7. Security Considerations

   If a malicious entity knows that a pair of hosts are communicating
   using a fragmented stream, it may be presented with an opportunity to
   corrupt the flow.  By sending "high" fragments (those with offset
   greater than zero) with a forged source address, the attacker can
   deliberately cause corruption as described above.  Exploiting this
   vulnerability requires only knowledge of the source and destination
   addresses of the flow, its protocol number, and fragment boundaries.
   It does not require knowledge of port or sequence numbers.

   If the attacker has visibility of packets on the path, the attack
   profile is similar to injecting full segments.  Using this attack
   makes blind disruptions easier and might possibly be used to cause
   degradation of service.  We believe only streams using IPv4
   fragmentation are likely vulnerable.  Because of the nature of the
   problems outlined in this document, the use of IPv4 fragmentation for
   critical applications may not be advisable, regardless of security
   concerns.
---


From: Aaron Campbell <aaron at arbor.net>
Date: Sat, 7 Sep 2013 08:27:47 -0300

> On 2013-09-06, at 1:42 PM, Robert Edmonds <edmonds at mycre.ws> wrote:
> 
> > Aaron Campbell wrote:
> >> Here is a thought, but I will defer to the protocol experts on plausibility.  The resolver knows the size of each DNS message it parses.  What if it didn't trust glue records contained within large (i.e., > 1400 bytes or so) responses?  In these cases, the resolver sends a separate query to resolve the dangling authority NS records.  This introduces overhead, but only for large replies.  It also makes a few assumptions, namely that the fragmentation point is something around 1500 bytes (and not something lower), and that the attack is only practical against the glue records, not the authority section.  May be able to play games with name compression there though… perhaps it is as least worth discussing as an additional barrier.
> > 
> > this sounds vaguely similar to unbound's "harden-referral-path" option,
> > though it applies to all lookups.
> 
> 
> I researched this, and found that it was first described here:
> 
> http://tools.ietf.org/html/draft-wijngaards-dnsext-resolver-side-mitigation-01#section-3.3
> 
> The option is currently marked "experimental" due to not being RFC standard, and performance concerns.  If the option were applied only to large responses (specifically to mitigate this type of attack), that would reduce the performance impact.
> 
> -Aaron
> _______________________________________________
> dns-operations mailing list
> dns-operations at 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
>