Chromium based browsers leak user local IP via WebRTC foundation attribute | Hacker News Reader

Chromium based browsers leak user local IP via WebRTC foundation attribute

niespodd.github.io

Many comments on this thread are about the pros and cons of leaking the local IP in an ICE candidate entry. You can certainly discuss this, but in my understanding, that's not what this post is about at all.

The issue is about leaking the local IP in the foundation which is supposed to be some sort of opaque UUID - the local IP isn't supported to be in there at all, whether you want LAN connections or not.

Is this correct?

Foundation was designed to be a tie breaker. If multiple candidates are valid with the same type you could use the lower foundation.

Foundation is specified in ICE RFC. Almost two decades before mDNS candidates were discussed! I doubt privacy of IPs was ever a consideration

This can be disabled in Brave by turning "WebRTC IP handling policy" to "Disable non-Proxied UDP" in "settings - > Privacy and Security".

perfect

In Chrome/Chromium there is a WebRTC Network Limiter [1] extension that let you set "Use only my default public IP address" policy and render the method I presented ineffective.

[1] https://chrome.google.com/webstore/detail/webrtc-network-lim...

Google abandoned that extension in 2016, which is why the last option (for disable_non_proxied_udp) is greyed out.

> This can be disabled in Brave by turning "WebRTC IP handling policy" to "Disable non-Proxied UDP"

Not advised if you want to use WebTorrent, since it relies on WebRTC.

Setting it to "Default public interface only" still allows WebTorrent & WebRTC-reliant tools to be used, whilst still only broadcasting your public IP (which is already known anyway).

What’s the issue there? How is knowing the local IP a security issue?

And FWIW, the local IP does not get leaked when using a VPN. (edit: Or rather, the VPN local IP gets leaked. Same question, no idea if that’s security relevant in some way?)

edit: Thanks everyone, I completely forgot about fingerprinting.

It's both security and privacy issue. Whonix wiki explains the latter in more detail https://www.whonix.org/wiki/Data_Collection_Techniques#:~:te...

If you use Chrome-exclusive links, please at least also link to the closest standard section [0] and preferably, mention the Chrome-linked text directly.

That said, they don't say anything about security, I obviously forgot about fingerprinting, but still don’t see security issues?

[0] https://www.whonix.org/wiki/Data_Collection_Techniques#Finge...

Leaking any kind of data is yet another data point for fingerprinting. You only need a few to uniquely identify a user.

I've yet to see a normally configured browser _not_ be uniquely identifiable many times over through fingerprinting.

At some point it feels like trying to drain the ocean with a cup. Maybe we just need to accept that anyone who really wants to fingerprint you _can_ fingerprint you unless you use a specialist browser.

At that point the solution is fairly obvious, make it legally difficult to use unique fingerprinting and move on (ie stuff like gdpr). People will still do it, but they'll have to balance it with not falling foul of the law and wont be able to abuse it too much.

We wont stop real world facial recognition by all trying to make our faces more similar either, we have to accept it's generally possible to do, but discourage the actual doing of it rather than trying to make it impossible.

(note in both cases, actually preventing it when you have a reason to is totally possible and valid, via specialist browser modes and physical masks respectively)

I just tried a clean FF profile with resistFingerprinting enabled. No dice. Everything adds only very few bits of identifying information (unlike my main profile which is already almost unique thanks to the accept header (English, then German)) yet it still results in 17.75 bits which according to EFF is unique.

I’m agreeing with you, though I wonder, is there any way to not be unique? What would you have to do? Use Windows with no extra fonts, Chrome in English, on a FullHD monitor with webgl/canvas/audio fingerprinting protection extensions?

I believe the only feasible way without bending over backwards is to use the Tor Browser. But privacy and security always come at a price.

Actually, resistFingerprinting + switching to the user-agent string tor uses gets me 99% of the way there. All that’s missing is the weird window size (vertical taskbar), if I could get that to report a default size, I’d actually be better than Tor (they have a bunch of responses slightly more unique than FF with resistFingerprinting).

But it’s academic for me anyway, I have Accept-Language en-US,en;q=0.7,de-DE;q=0.3 which is close enough to unique that nothing else really matters.

> All that’s missing is the weird window size (vertical taskbar)

TBB actually adds a border at the bottom of the browser so the reported size isn't the actual size. If you change the size of your browser window to the tor-reported size then it should work.

Unless I'm misunderstanding and you mean something to do with the scrollbar?

I think a HTML-only browser without support for CSS and JS might help.

How many people do you know run html only browsers? Not having CSS would be extremely uniquely identifying.

Disabling JS is enough to almost perfectly fingerprint you.

Yes and you probably “haven’t watched television in 20 years”.

The EFF has a website that illustrates why that doesn't help:

https://coveryourtracks.eff.org/

Like siblings are saying, they use all available information to fingerprint you.

You can cover your identity only to the extent that you can display the same characteristics to the web server as the largest group of users that have all the same characteristics. This includes whether you have JS disabled as well as your IP address, User-Agent, display resolution, etc.

> We wont stop real world facial recognition by all trying to make our faces more similar either

The normalization of mask wearing in public was a great step towards this. I really wish it had gone better. Alas!

Yeah. All that's needed is to leak link-local IPv6 address from a single interface. There's your unique commputer identifier, unless someone's using mac randomization.

> How is knowing the local IP a security issue?

It's a privacy issue. You can use it to fingerprint a user, local IP will give you quite many bits of entropy. <https://coveryourtracks.eff.org/>

Honestly I'm not even sure if I'm surprised, but it's 2022 and we've been having this problem basically since the day WebRTC was introduced. At this point, if you care about privacy, you should probably put it in the same bag as third-party cookies and just block it entirely.

Well, the big non-adtech browser is not vulnerable, so there’s that.

https://bugzilla.mozilla.org/show_bug.cgi?id=959893 is a fun read... Firefox used to also leak the internal IP circa 2015.

Yes it is interesting how developers race to push new features allowing deanonimization of VPN users and better fingerprinting.

There is also WebGL whose main purpose is to provide user's videocard model to advertising companies and governemnt institutions.

If memory serves Ublock origin does just that.

Not anymore on Desktop: https://github.com/gorhill/uBlock/wiki/Prevent-WebRTC-from-l...

It's because if you don't leak the local IP, then webRTC calls will typically fail between people on the same LAN. And, if they don't fail, then they will usually have to go via a TURN server on the internet adding a lot of latency.

It's a privacy/functionality tradeoff. But most people consider not being able to videocall or do online gaming with someone in the same building to not be acceptable.

I don't think that there are many people using WebRTC especially within the same LAN, but fingerprinting is used by almost every commercial site. So I can assume that this "feature" was used in 99.99% cases for fingerprinting.

This shows how browser developers race to push new features without proper estimation of privacy concerns.

Luckily this was somewhat fixed by using randomized Apple mDNS names instead of IPs. But as a result the browser has to support Apple DNS protocol which can potentially increase attack surface.

I would prefer to disable this feature completely by default and let the minority who needs it enable it via settings.

Corporate networks…

> This shows how browser developers race to push new features without proper estimation of privacy concerns.

Settling on a different trade-off then you would like is not the same thing as doing it without consideration.

In this case, it is blatant disregard.

> But as a result the browser has to support Apple DNS protocol which can potentially increase attack surface.

The "Apple" DNS protocol is standard DNS, over a multicast IP address, on port 5353. You can literally use plain old dig to perform mDNS lookups:

    $ dig @224.0.0.251 -p 5353 +short hello.local

    192.168.123.45

If DNS lookups considerably increase your attack surface, something is very, very wrong with your architecture.

> literally

The DNS names WebRTC generates for this purpose are random, and known only to the signaling participants.

I remember old BIND versions

>I don't think that there are many people using WebRTC especially within the same LAN

Zoom/Teams with people in the same office? That seems like a rather large user base

Almost all of the “sales/demo/cross company” video calls I’ve been on have been in this bucket

> Almost all of the “sales/demo/cross company” video calls I’ve been on have been in this bucket

My understanding is Zoom only supports P2P for two person calls.

I can't quite tell from this answer if it is the default or not, but it sounds like it has to be manually enabled:

> Account owners and admins can enable one-on-one meetings to have data routed between two participants (peer-to-peer), rather than going through the cloud or server. Enabling this may improve the quality and connection of one-on-one meetings (depending on how your network prioritizes traffic) by directly sending video and audio between both parties.

https://support.zoom.us/hc/en-us/articles/360061410851-Enabl...

I see a lot of WebRTC usage just in the LAN. WebRTC sees a lot of usage outside of conferencing!

* Controlling Robots (formant.io)

* Security Cameras

* File Sharing

* Game Streaming/VNC

I keep a list of interesting open source WebRTC projects at https://github.com/pion/awesome-pion

They use MDNS hostnames to keep WebRTC working on LANs without leaking the IP itself, this was just an extra leak they didn't catch.

Are you sure? I bet most people have never even tried to do that.

> It's a privacy issue. You can use it to fingerprint a user, local IP will give you quite many bits of entropy. <https://coveryourtracks.eff.org/>

I don't buy it: You have to block IPv6 as well, and that's becoming harder to do.

If the user is trying to protect their "privacy" from their ISP by using a VPN (for example), and are attempting to prevent the application-level leak of providing a list of all the local interfaces, they really need to configure their system to restrict e.g. their web browsers and other sensitive tools to those specific interfaces, e.g.

https://askubuntu.com/questions/1313755/forcing-chrome-brows...

This should be easier, like maybe a button in the VPN software.

> just block [WebRTC] entirely

I think an opt-in permission seems like the way to go, like the one we already have for microphone/camera permissions, and possibly just merged with these (i.e. grant WebRTC permissions together with A/V permissions).

There are quite a few interesting non-A/V WebRTC applications around – these could be handled via an explicit prompt, similarly to how newer iOS versions handle local network permissions.

Have a look at this that scans your local network: http://samy.pl/webscan/

I think some browser changes might have hobbled it a bit, but it was startling when I first tried it.

A bit? The site claims it found a host on literally every single private IP that exists ;) And closing it nearly killed my FF (full freeze for ~10 seconds).

OTOH, using Mobile Safari, this site leaked my device’s IP as well as a number of connected devices on my internal network.

Anyone know an easy fix for this?

If so, I'd love to hear it. As far as I know all iOS browsers are forced to use the same rendering engine, and I suspect there's no way to modify that.

WebRTC was already known to leak local IP. Which can be dangerous if you're behind a VPN.

I use two browsers. One with WebRTC disabled (Firefox) and one with WebRTC enabled (Safari/Chromium). The former also runs a myriad of other addons which increase privacy. The latter I use to connect to PiKVM.

I also use similar browser isolation strategy. I use one browser for real-ID activity such as banks, domain registrars.. and avoid entering real creds in the private browser to keep an anonymous fingerprint. This is one of those gray areas though where I don't always want to share my IP over Jitsi.

> The former also runs a myriad of other addons which increase privacy.

Unfortunately, the more custom your browser behavior gets, the more finger-print-able you are :/

And that's not even considering potentially harmful plugins (either inherently so, or via browser store account takeovers).

It used to be available to detect, but they changed it a long time ago.

It made it easy to help someone find their local ip address, without having to click around in settings or the command line:

https://www.whatismybrowser.com/detect/what-is-my-local-ip-a...

But I understand the fingerprinting/privacy concerns, so it's for the best that it's not available.

If you are unfamiliar with WebRTC I recommend checking out "WebRTC for the Curious":

https://webrtcforthecurious.com/

WebRTC is designed to be secure, so a privacy leak is not good.

WebRTC is designed to support direct peer-to-peer connections so the privacy leak is required.

Maybe it would have made more sense to make peer-to-peer opt-in explicit?

I liked that idea also.

The concern was dialog fatigue. If a web site prompts permission to ‘gather local candidates’ most users are just going to hit OK. So this wouldn’t stop abusive uses of WebRTC as hoped.

Glad you liked it! Anyway we could make it better?

I am using Microsoft Edge and the test on the linked page times out without detecting anything. Perhaps it is because I've enabled the "Anonymize local IPs exposed by WebRTC" flag.

Has this been reported to Chromium / WebRTC? At a quick glance I don't see it in the WebRTC bug tracker.

The root technical issue here seems to be that the IPv4 space is fundamentally pretty small and easy to search, the browser just uses a crc32 to obscure the local IP address, and you can write code to brute force it with a little sophistication.

The security impact, as others are pointing out, is pretty minimal. Knowing a local IP address behind a NAT isn't "not" a privacy issue (e.g. I can see things like gaming anti-abuse using tricks like this to discriminate users who need to be blocked vs. normal players), but it's not much of one.

How to disable WebRTC on Firefox Mobile? I have uBlock which prevents from leaking the local IP but I don't want WebRTC at all.

Why did they take about:config from us?

Damned if you do, damned if you don’t. Disabling WebRTC would make your Firefox instance extremely unique and thus easily fingerprinted.

Yes, but as far as I understand, the fight against fingerprinting is lost anyway.

Having WebRTC enabled can be dangerous for other reasons. You could be seeding a torrent unknowingly just by visiting a website. This can turn into a freaking disaster if you live in country like Germany.

It's a shame that browsers don't ask you for WebRTC like they do with webcams.

Was I wrong about the torrent stuff or did the downvotes come from web-developers who want WebRTC to be always available by default?

Well for one a website can make you secretly upload copyrighted content with plain old javascript. And it's going to be hard to hold you liable for data uploads that someone else initiated and you didn't know about.

> Well for one a website can make you secretly upload copyrighted content with plain old javascript

Only to a webserver and thanks to CORS not to any webserver. There is no benefit for a website doing that - unlike with sharing a torrent to other internet users.

The problem with torrents is that they are actively watched by "Abmahnanwälte" (lawyers who make a living by suing copyright offenders).

> And it's going to be hard to hold you liable for data uploads that someone else initiated and you didn't know about

yeah good luck with that. All they see is your IP and then you can try to explain how this happened and how you are totally innocent.

Yeah, that one was as annoying as what they did to extensions, but at least the Fennec build in F-Droid has it enabled.

https://f-droid.org/en/packages/org.mozilla.fennec_fdroid/

Thank you, I will try that. Although I hope that for critical security updates they will be faster... Right now it is lagging behind (105.1.0 vs. current 106.1.0)

I was wondering about that myself: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/11924

Looks like they ran out of space on their build machine.

> Why did they take about:config from us?

What do you mean? I'm running the latest firefox nightly from the play store and I can see the about:config...

Yeah. It's only available in nightly. Which is fine so long as you're ok with things occasionally breaking or sudden vulnerabilities (I've dogfooded nightly on desktop and mobile for years and it definitely happens. Happened to me just last week) and you also have to be fine with downloading a huge package and writing it to your internal card basically every day which may be an issue with your plan, and after a few years, is also an extra thousand writes that you might have wanted to avoid (my last 3 phones have had replaceable batteries but not internal storage).

about:config is only available in Beta or Nightly on Android now, though forks like Fennec also have it enabled by default.

They took it away in Stable because changing some settings may disconnect GeckoView from the application containing it and they can't have that.

I run Beta for this reason. Nightly is too unstable for me so I had to give up custom addon lists to bypass Mozilla's outdated whitelist (they were only available in nightly for a while, I believe that's in Beta now).

Mozilla doesn't trust you to use their precious software right and they'll take away your toys if it considers you to be playing with them wrong. I still like Mozilla over Google, Microsoft, and Apple, but it's really hard to be a fan of Firefox when they pull shit like this.

* https://github.com/gorhill/uBlock/wiki/Prevent-WebRTC-from-l...

* https://browserleaks.com/webrtc

Is user IP leaked to another peer if there is a media server (like Kurento) between peers? I’ve worked in 2 WebRTC-based projects and in both cases the connection was not actually P2P, but had some kind of media server in between, either to mux multi-user conferences or to re-encode the media to a format supported by the other peer.

I'm not getting a leak with Chromium, but that is probably because I have my policy set to `default_public_interface_only`. I believe this is by design as WebRTC notoriously leaks local IPs.

WebRTC again. On the same page. There is no isolation between remote and local networks in browsers.

I seem to recall Fallon (based on Chromium) has a feature which disables that.

You appear to be correct. I just tried the test on Falkon and it failed. But since not many poeple use Falkon regularly... maybe that's a fingerprint all by itself.

> But since not many poeple use Falkon regularly... maybe that's a fingerprint all by itself.

You can check here: https://coveryourtracks.eff.org

What does "Used 0 keys for lookups" mean?

From what I can tell it is taking the local IP it finds and then looking it up in a database. If it doesn't find any IPs then it reports used 0 keys for lookup.

So in this case it means you're not vulnerable.

I think uBlock Origin prevents that.

see Semaphor's comment above: https://news.ycombinator.com/item?id=33328486

It gets "leaked" to a web app that I'm choosing to connect to? Why do I care?

Yeah we don't need privacy, especially to third party extensions loaded by sites, we should just set our user agent to our full name, address and phone number.

I know you said this as a joke, but I think you underestimate the convenience draw of that. Already if I have to sign up for something on not-my-primary-computer I'm annoyed because I can't use the Chrome autofill to take care of entering my address/phone/credit card details. For a large number of people the privacy concerns take a definite backseat to seamless and quick experiences and there isn't anything wrong with making that value judgement.

Your full name is not the same as your local IP. Since your NAT subnet is almost always /24, there really are only 256 local IP addresses. Which one you happen to be using at the time is not really important. There are 10,000 other things about your browser that could be used to uniquely identify you. This is a feature of WebRTC that allows it to do what it does, not a bug. If you are worried about 3rd party web apps sniffing your local IP and somehow using that info against your interests, don't go on the internet.

If it leaks local ipv6 there may not even be NAT involved. This would unmask the user on the other end of a VPN or Proxy, for example.

While this generation is done only for IPv4 space someone with sufficient time, resources, and inclination (say a large Ad conglomerate) could similarly start generating these for IPv6 address spaces.

Reply on news.ycombinator.com