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]
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
Even though you can set a firewall to prevent external actors from exploiting this flaw, I believe this can still be considered a security issue/flaw, because it allows an attacker on the intranet to DDoS external entities. Yes, you could set the firewall explicitly to filter out requests originating from port 5353 and with dst port 53, but I believe this is not a so common thing to do (you do not usually filter dst port 53 because of DNS, so everybody who has Avahi on at least one of his devices should configure the firewall) Thus I think it would be better to just fix the flaw at the avahi-daemon level. CVE-2018-1000845 seems to be a duplicate of this flaw. I'd like to request duplicate-rejection to MITRE for CVE-2018-1000845 and reopen this bug. Thoughts?
> I believe this can still be considered a security issue/flaw, because it allows an attacker on the intranet to [D]DoS external entities. Fair enough, I agree this is a legitimate concern though the impact remains low given firewall mitigations and the rate-limiting you pointed out in bug 1661252. > CVE-2018-1000845 seems to be a duplicate of this flaw. I'd like to request duplicate-rejection to MITRE for CVE-2018-1000845 and reopen this bug. Thoughts? Agreed, it looks like a duplicate. There seems to be some confusion about IPv4 vs IPv6, but the upstream discussion indicates a common root cause & patch.
Setting Availability in CVSSv3 to Low because of the rate-limiting feature enabled by default in Avahi, that allows to generate a maximum of 1000 packets per second (which can be configured with the ratelimit-interval-usec and ratelimit-burst options in /etc/avahi/avahi-daemon.conf).
Mitigation: Ensure UDP port 5353 is blocked in the firewall. Moreover, configure correctly the rate limiting options based on your needs (see ratelimit-interval-usec and ratelimit-burst options in /etc/avahi/avahi-daemon.conf).
Upstream patch: https://github.com/lathiat/avahi/commit/e111def44a7df4624a4aa3f85fe98054bffb6b4f
Re-opening bug for reasons explained in comment 5.
*** Bug 1661252 has been marked as a duplicate of this bug. ***
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2020:1176 https://access.redhat.com/errata/RHSA-2020:1176
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2017-6519