|Summary:||CVE-2017-6519 avahi: Multicast DNS responds to unicast queries outside of local network|
|Product:||[Other] Security Response||Reporter:||Adam Mariš <amaris>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||NEW ---||QA Contact:|
|Version:||unspecified||CC:||abhgupta, antonios.atlasis, dbaker, dmoppert, jokerman, lpoetter, msekleta, psampaio, rdieter, slawomir, sthangav, trankin|
|Target Milestone:||---||Keywords:||Reopened, Security|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2017-04-06 02:42:15 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||1426717, 1663410, 1663417|
|Bug Blocks:||1426716, 1661254|
Description Adam Mariš 2017-02-24 16:22:55 UTC
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
Comment 1 Adam Mariš 2017-02-24 16:29:51 UTC
Created avahi tracking bugs for this issue: Affects: fedora-all [bug 1426717]
Comment 3 Doran Moppert 2017-04-06 02:40:43 UTC
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.
Comment 4 Antonios Atlasis 2017-04-14 19:48:00 UTC
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
Comment 5 Riccardo Schirone 2019-01-02 14:49:39 UTC
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?
Comment 6 Doran Moppert 2019-01-03 00:22:51 UTC
> 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.
Comment 7 Riccardo Schirone 2019-01-04 08:31:01 UTC
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).
Comment 8 Riccardo Schirone 2019-01-04 08:31:07 UTC
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).
Comment 9 Riccardo Schirone 2019-01-04 08:36:37 UTC
Comment 11 Riccardo Schirone 2019-01-04 08:38:35 UTC
Re-opening bug for reasons explained in comment 5.