Bug 1426712 (CVE-2017-6519) - CVE-2017-6519 avahi: Multicast DNS responds to unicast queries outside of local network
Summary: CVE-2017-6519 avahi: Multicast DNS responds to unicast queries outside of loc...
Status: NEW
Alias: CVE-2017-6519
Product: Security Response
Classification: Other
Component: vulnerability   
(Show other bugs)
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=low,public=20150331,reported=2...
Keywords: Reopened, Security
: CVE-2018-1000845 (view as bug list)
Depends On: 1426717 1663410 1663417
Blocks: 1426716 1661254
TreeView+ depends on / blocked
 
Reported: 2017-02-24 16:22 UTC by Adam Mariš
Modified: 2019-03-21 06:12 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-04-06 02:42:15 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

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
Upstream patch:
https://github.com/lathiat/avahi/commit/e111def44a7df4624a4aa3f85fe98054bffb6b4f

Comment 11 Riccardo Schirone 2019-01-04 08:38:35 UTC
Re-opening bug for reasons explained in comment 5.

Comment 15 Riccardo Schirone 2019-01-31 08:18:03 UTC
*** Bug 1661252 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.