mDNS candidates allows determination of computer hostname

[Sean-Der]

Currently Safari+Chromium allow any mDNS name to be used for lookups. This means I can run a query for things like the computers hostname. I whipped up a little demo here [0]

Do you think it would be a good idea to edit [1] and require that lookups only be done against UUIDs as well?

[0] https://jsfiddle.net/10eq2rzh/ [1] https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-04#section-3.2.1

Quoting @youennf

This is somehow related to https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-04#section-3.3.4. I guess we should probably forbid using mDNS candidates that resolve to the same device and are non UUID. MUST seems ok to me since a local application that wants to webrtc with a page can always generate a UUID for that specific purpose.

When it resolves to another device, the attacker would probably need to control both devices. This does not seem like an issue here (correct?), although I do not see any practical benefit of resolving non UUIDs either.

Quoting @juberti

This is discussed briefly in https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-04#section-3.2.2, i.e., that user agents may want to only resolve UUIDs. We may want to call out this additional consideration (which is complicated by the fact that one has to know the machine name a priori) in the security considerations section.

[Sean-Der]

Happy to remove the quoting if it isn't useful, but seems like really good points. thanks!

[fippo]

ugh, that works like charm. Requiring .local seems like a good way to prevent this.

Related, it might make sense to block a couple of hostnames explicitly. Resolving hosts like the german fritz.box and speedport.ip (SOHO routers) adds to the fingerprinting surface

[lgrahl]

Not sure if you're aware of it but I've checked your script and you can also use it to determine mDNS hostnames of other devices within the network.

Background: Chrome currently uses a 25s timeout for ICE checking.

If ICE is still in checking briefly after 25s, this means the hostname doesn't exist in your network. Because if the mDNS hostname cannot be resolved, ICE never goes into disconnected/failed as it does not have a valid ICE candidate.

If however the mDNS hostname could be resolved, ICE fails with state disconnected/failed after 25s. This means the hostname exists in your network and it is another device.

If ICE goes into connected, it means the hostname refers to your device.

This is a powerful tracking/fingerprinting tool...

[juberti]

These are good observations. I don't think this is a critical issue, as it seems impractical to guess the local hostname, and Chrome will already ignore non-.local mDNS names (at least, it should, per https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-04#section-3.2.1). This means that fritz.box and other well-known mDNS names should not present an issue (please correct me if I am wrong here).

However, this suggests the following changes: 1) it probably makes sense for Chrome to limit to {uuid}.local until we see a clear need for resolution of non-uuid mDNS names, otherwise we're just creating additional attack surface that we need to spend time thinking about. This should be called out explicitly in the security considerations part of the spec. 2) when mDNS resolution fails, we should generate some sort of dummy candidate so no information about mDNS success/failure is leaked. This would necessitate a change to https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-04#section-3.2.1; perhaps 0.0.0.0 and :: should be used as the dummy values.

[juberti]

@tQsW who will have thoughts here

[juberti]

Discussed this with @tQsW and noted a few things:

• the attack noted by @lgrahl would not be possible if the ice-pac timer was implemented, since ICE should go to the failed state after the ice-pac timer expires.
• however, one could still use ICE stats to determine the resolution failure since the candidate wouldn't appear in ICE stats
• using the pseudo-IP as noted above should address this though

[Sean-Der]

@lgrahl @fippo oh that is a really clever idea! I had no idea you could determine if a device exists (or not)

My NAS has a dedicated .local, I bet you could build a pretty unique fingerprint of a user by asserting what common devices they are running.

sean@SeanLaptop:~$ avahi-browse -a
+ wlp3s0 IPv4 WDMyCloud                                     _wd-2go._tcp         local
+ wlp3s0 IPv4 WDMyCloud                                     Web Site             local
+ wlp3s0 IPv4 WDMyCloud                                     Apple File Sharing   local
+ wlp3s0 IPv4 38f9d359441f                                  Network File System  local
+ wlp3s0 IPv4 WDMyCloud [00:14:ee:1b:45:2e]                 Workstation          local
+ wlp3s0 IPv4 38f9d359441f [38:f9:d3:59:44:1f]              Workstation          local
+ wlp3s0 IPv4 38f9d359441f                                  SFTP File Transfer   local
+ wlp3s0 IPv4 38f9d359441f                                  SSH Remote Terminal  local

sean@SeanLaptop:~$ avahi-resolve -n WDMyCloud.local
WDMyCloud.local 192.168.1.7

[youennf]

Closing issue based on the above PRs. @Sean-Der and others, let me know if the ToT version of the spec is good with you.