Re: [dnsext] A security concern regarding IPv6 support in name servers

[Alfred Hönes <[e-mail]>]

Nicholas,
I do not share all of your explanations, in particular with RFC 5452
in mind.

> On Sep 20, 2010, at 5:28 AM, Alfred Hönes wrote:
>
>> I have been pointed to a paper by H. D. Moore published in 2008,
>> "Exploiting Tomorrow's Internet Today - Penetration Testing with IPv6",
>> available at <http://uninformed.org/?v=10&a=3&t=pdf>.
>>
>> On page 3, this paper points out that Bind running on an IPv6-enabled
>> system, unless its serving socket is bound to a specific IPv6 (unicast,
>> interface-assigned) address of the system, also listens to multicast
>> traffic (the memo apparently confuses the terms "broadcast" and
>> "multicast") and will also respond to DNS queries received over IPv6
>> multicast (e.g., to FF01::1).  This could be leveraged for discovering
>> nodes and for various amplification / DoS attacks.
>
> Except that if you are on the multicast domain of the victim, the
> victim is already screwed for reconnisance, because the other systems
> (eg, Macs, windows, etc) use multicast link-local and network-local
> IPv6 a lot for autoconfiguration.
>
> Just listening, let alone generating, traffic to the link local
> multicast will pretty much tell you everything in the network you
> might want to exploit.

All agreed so far.

> And in fact the victim is just screwed because you can use ICMP6
> router advertisements etc to direct the victim's internet traffic
> wherever you want to go.

Right, but thereby services running on nodes cannot be identified.


> Basically, if an attacker is within your IPv6 subnet (so
> link-local/site-local multicast works) you are totally lost.

The primary question is whether you (as a DNS server) can/should
avoid actively contributing to the success of an attacker.


> And thus responding to requests on multicast is probably a Good Thing,
> as it enables inside-the-perimeter autoconfiguration and fallback,
> multicast-dns support, etc.

The question was *not* posed wrt mDNS / LLMNR; it specifically was
targeted at 'classical' (== standard) DNS service offered at port 53.

My reasoning is that a resolver following RFC 5452 will drop any
response to a multicast DNS query because that response cannot be sent
with the destination multicast address of the query as its source
address (the IP layer of the server will hopefully prohibit this)
and hence the src<->dst {addr,port} matching rules of RFC 5452
will declare the response as invalid.

So why would a DNS server want to send a response packet to a
multicast query, if any conforming recipient (resolver) will
drop the packet anyway?  And if the src addr of the query was
spoofed, the DNS server would contribute actively to an attack.

Kind regards,
  Alfred.