Red Hat Bugzilla – Bug 1426712
CVE-2017-6519 avahi: Multicast DNS responds to unicast queries outside of local network
Last modified: 2017-05-02 04:48:30 EDT
It was found that avahi responds to unicast queries coming from outside of local network which may cause an information leak, such as disclosing the device type/model that responds to the request or the operating system. The mDNS response may also be used to amplify denial of service attacks against other networks as the response size is greater than the size of request. External References: https://www.kb.cert.org/vuls/id/550620
Created avahi tracking bugs for this issue: Affects: fedora-all [bug 1426717]
Mitigation: Ensure UDP port 5353 is blocked at the firewall.
While all versions of avahi seem to be affected, for reasons discussed at the CERT link above this is not strictly a security bug. > While this technically follows established RFCs and is not a vulnerability in the normal sense, for reasons outlined above this may be unwanted behavior. avahi could be enhanced with a configuration option controlling this behaviour, but blocking inter-segment mDNS traffic is, in general, a task better performed at the firewall.
Hi First, if it is not a bug, why this was fixed for IPv4? Avahi used to be affected over IPv4 (as the above link staes) but this is not the case any more (I have tested personally). Secondly, as RFC 6762 Section 5.5 states: "Since it is possible for a unicast query to be received from a machine outside the local link, responders SHOULD check that the source address in the query packet matches the local subnet for that link (or, in the case of IPv6, the source address has an on-link prefix) and silently ignore the packet if not." Be aware though that the word SHOULD above is not the English word 'should', but as stated in RFC 2119 "This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course". Moreover, the statement on the aforementioned link does not say that this is not a security issue, but this is not a vulnerability in the normal sense, depending on the RFC interpretation, of course (I tried to clarify it above). As an example, Type 0 Routing header was defined in RFC 2460 (and hence, its support should not be a vulnerability in the normal sense), but it was deprecated with RFC 5095 when it was found out that it can be used for DoS amplification attacks. Finally, major vendors like Apple, Google, Cisco, Microsoft, etc. do not allow remote unicast interaction, neither over IPv4, nor over IPv6 (I have tested the first two, this is stated for the last two in the aforementioned link). Kind regards Antonios