1466148 - WebRTC leaks internal addresses even when camera/mic permissions are not granted

Status: NEW

(Core :: WebRTC: Networking, enhancement, P3)

Description

[Gian-Carlo Pascutto [:gcp]]

During a discussion about fingerprinting/privacy aspects of WebRTC, the following statements were made:

<abr> Local IPs aren’t used unless permission has been granted to access camera or microphone. Which is almost, but not exactly, the same as “datachannel-only connections don’t use local IPs”

This was echoed by jesup.

However, tritter quickly confirmed that this is NOT the case even on Nightly: the internal LAN IP gets exposed in all cases.

Reading a bit into:
https://wiki.mozilla.org/Media/WebRTC/Privacy

It seems only addresses along the default route are exposed, but this doesn't preclude internal IPs at all - in fact for most users there won't be a difference as they have a single interface.

We should verify if this was intentional or an oversight, or due to an incomplete implementation.

Comment 1

[Gian-Carlo Pascutto [:gcp]]

During the discussion this was linked: https://bugzilla.mozilla.org/show_bug.cgi?id=1304600#c5

Reading carefully, none of the preferences strictly catches the behavior described above, i.e. to not leak internal IPs unless permission is given.

Comment 2

[Gian-Carlo Pascutto [:gcp]]

https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-04

Mode 2:  Default route + associated local address

Mode 3:  Default route only: This is the the same as Mode 2, except
         that the associated private address MUST NOT be provided.

In cases where user consent has not been obtained, Mode 2 SHOULD be
used.  This allows applications to still achieve direct connections
in many cases, even without consent (e.g., data channel
applications).  However, user agents MAY choose a stricter default
policy in certain circumstances.

So the spec does say we do the right thing, but also gives some leeway to improve the privacy behavior? I would think that the major victim of such a change would be WebRTC applications doing large non-video data-transfers over a local network.

Comment 3

[Gian-Carlo Pascutto [:gcp]]

During the discussion, https://www.sharedrop.io/ was given as an example of an application that would be highly problematic with Mode 3 defaults. (There is, after all, no permissions prompt for datachannel use, and such a site would not want to request access to the mic, which would send users away)

Comment 4

[Gian-Carlo Pascutto [:gcp]]

So, in conclusion, the current behavior is intended and as per spec (even if 2 WebRTC networking engineers misremembered!). The IPs that are not exposed without permissions are those of *secondary* interfaces, for example in VPN scenarios. The local IP of the default route is still exposed.

It's possible to do better but only at the cost of breaking a lot of DataChannel applications. We currently judge not breaking those to be a better user trade off than the fairly marginal fingerprinting and security impact of leaking internal IPs along the default route. But note that Safari has made a choice the other way around, i.e. in favor of not leaking user IPs.

It's possible to get finer grained control via extensions in Firefox. But I have a remark here: I use uBlock Origin, which is one of the most popular extensions. If I enable "Prevent WebRTC from leaking local IP addresses" then https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ complicate fails. It doesn't just report local IPs, it seems to completely break ICE. So perhaps shoving off this responsibility to extensions is backfiring.

Comment 5

[Gian-Carlo Pascutto [:gcp]]

The uBlock Origin bug is long known and long-standing and partially caused by similar flags having a different meaning in Chrome (due to Chrome bugs?): https://github.com/gorhill/uBlock/issues/3009

So if a user tries to get the effect of mode 3 defaults via the most accessible way to do so, they'll just end up disabling WebRTC entirely instead.

Comment 6

[Dave Andrews]

Is there a way to make the mode selected, operate like any other normal permission dialog (Location, Notifications, Autoplay, etc)?

To me this seems like a pretty high-level question that users should understand:

"The website <xxx.yyy.zzz> is requesting access to private network devices. Would you like to grant it access?"
[ ] Remember my decision every time i visit this site.
Yes | No

Once they press 'Yes', do something like reload the page, or if possible, provide the delta between whichever modes you're switching between via the Javascript API (akin to a user plugging/unplugging network interfaces, from Javascript's standpoint). "Network" could then be one of the normal permissions that each website is allowed to get access to by using, just like Location, Notification, etc.

That way at least people can be made aware of all the abuse that WebRTC is probably getting in the wild for fingerprinting, but also provides an education path for the kind of physical access it opens up.

Even with an approach like this, Mozilla can pick whatever defaults it needs to comply with spec for such a "Network" permission (e.g. "always enable") -- and should default to whatever provides the least tension for any kind of express route that majority of users will fall into, while balancing those needs against more privacy-conscious folks.

Another place for inspiration: Autoplay permissions has a "Default for all sites" drop-down in their permissions section for sites that the user has not added exceptions, with 3 separate options in it. This seems like the kind of place to put Mozilla's choices for defaults on "Network Access" for selecting outcomes that line up with Mode 1, Mode 2, and Mode 3. They shouldn't make such an option implied via Mic/Video confirmations if it's doing MORE than just granting access to Mic/Video, and Firefox really should not be interpreting other permissions like Mic/Video to literally mean "Network Access", when there is nothing about that implied! (That is, unless you'd be doing Mic/Video permissions checks in addition to network permissions checks).

I think the concerns of privacy advocates is that, from a fingerprinting standpoint , the lack of even being able to express such a per-site configuration makes working with WebRTC a nightmare, because the privacy advocates are always forced to enable/disable webrtc for the entire browser in about:config to avoid leaking private IPs -- even if there are individual sites (like sharedrop) that they've elected to trust. Or other privacy folks are outright confused, and they're turning to addons like uBlock because we've done a poor job disambiguating these.

WebRTC spec mentions UA prompts, but doesn't really elaborate on how you can turn what seems like an obvious bug that caused a fair bit of outrage some years ago into a really elegant feature.

Comment 7

[Dave Andrews]

A couple terms to clear this up. I believe this is everything the public would see (please correct me if I'm wrong)...

"Default for all websites:"

Mode	JS API	Phrasing
1	"all"	Enable Network Access
2	"public"	Enable Network Access on Default Connections only
3	"relay"	Disable Network Access

(The effect of mode 3 quite genuinely seems to mean 'private network access is disabled', because as far as I understand, only relay servers will work in that mode, so no fingerprinting or private network access occurs)

Combinations:

Default Mode	New Website requests Permission	Popup
1	1	No
1	2	No
1	3	No
2	1	Yes
2	2	No
2	3	No
3	1	Yes
3	2	Yes
3	3	No

My anticipation is that Mozilla would pick Default Mode = 2, because that's consistent with what they're trying to get to.

Effect of such a default with no exception would be:
-Websites that intentionally specify Mode 1 (aka "all") will see a popup.
-Websites that intentionally specify Mode 2 (aka "public") will not see a popup.
-Websites that intentionally specify Mode 3 (aka "relay") will not see a popup.
-Websites that accidentally don't specify a mode in their WebRTC usage will still see a popup, because JS defines default to "all".

The combination of Mode 2 as a browser default, and the JS api (when unspecified) left as Mode 1, would cause more popups is precisely what makes this awkward, but it seems to suggest that we would need either a "learning phase" for the Internet to adjust the privacy mess they've made, or another option to help the browser disambiguate what "all" means:

all The ICE agent may use any type of candidates when this value is specified.

^^ The wording here does not seem to say that "all are required", but more that "all are unspecified".

If we add "Block new requests for website access requests" in the Network Tab, and set it to checked by default, does that mean we can block ALL popups by default, AND have the default max mode, and just lock everything to mode max mode 2?

Alternatively you'd probably have to improvise some kind of new option, like a "Block new requests for website access requests meeting criteria ______".

Comment 8

[sworddragon2]

Is the initial or any remaining issue still present? Initially I planned to reply to bug #959893 comment #161 but the ticket is restricted and this referenced ticket seems to be suitable too to evaluate the current state. Around 2.5 years ago when I tested if my local IPv4 address can be leaked on websites for fingerprinting it succeeded which caused me to disable WebRTC via media.peerconnection.enabled=false to avoid the leakage. Yesterday I created a new firefox profile and evaluated all settings especially in terms of privacy/security and not a single website I did tests on was able to detect my local IPv4 address anymore when WebRTC was enabled thus making this issue seemingly not a threat at all anymore.

The question is now: Is that really true? It would be quite nice if one has not to bother anymore to disable WebRTC for maximum privacy or are there still edge-cases that could leak something unwanted and thus disabling WebRTC could be still an option? Or did all issues just resolve over time and this ticket (and eventually bug #959893 ) can be closed?

Comment 9

[sworddragon2]

I guess it is worth throwing a NI here for comment #8 as things seems to be unclear here and in the referenced ticket.

For bug #959893 it depends on the meta-ticket bug #1189167 which has as only open dependency bug #1189036 with no activity for ~6 years. Is this last ticket still relevant for the term "Internal IP Address Leakage" today or is this topic now mainly handled and if so does it solve this ticket here as well?