Live data from Hacker News

Excuse Me Sir, Your WebRTC Is Leaking

blog.golgi.io

31–39 of 39 posts

Re: Excuse Me Sir, Your WebRTC Is Leaking

#31
post #27
post #25

Earlier quoted context omitted.

Why would you want to disable STUN requests? Wouldn't they just return the public-facing IP that the server already knows about?

Did you even read the article and click the demo link? :) https://diafygi.github.io/webrtc-ips/

Yeah, but you don't even need a stun server for that. The browser itself provides the local IP addresses.

Re: Excuse Me Sir, Your WebRTC Is Leaking

#32
post #31
post #27

Earlier quoted context omitted.

Did you even read the article and click the demo link? :) https://diafygi.github.io/webrtc-ips/

Yeah, but you don't even need a stun server for that. The browser itself provides the local IP addresses.

Oh, I thought it had to read them back from the STUN server negotiation because of javascript limitations.

Re: Excuse Me Sir, Your WebRTC Is Leaking

#33

It seems like the problem that WebRTC wants to solve could be solved another way, by putting more of the discovery logic into the browser rather than the application. WebRTC wants to find peers on the local LAN, and communicate with them directly. Why not let the browser find peers, and then hand the WebRTC application a connection without exposing where that connection leads? That said, long-term, I think networks n…

[deleted]

Re: Excuse Me Sir, Your WebRTC Is Leaking

#34
post #24
post #4

Flash has been able to do this for years: https://tools.ietf.org/html/draft-thornburgh-rtmfp-flash-02#... The "setPeerInfo" command is sent by the client to the server over the NetConnection control flow to inform the server of candidate socket addresses through which the client might be reachable. This list SHOULD include all directly connected interface addresses and proxy addresses except as provided below. The li…

Flash can be blocked, or not installed. If you are running a modern Chrome or Firefox, there is no way to stop this from running. (edit: apparently you can now block WebRTC entirely in Firefox, but Chrome has to be recompiled)

I wish chrome had an advanced configuration interface similar to firefox's for this kind of thing... I'm actually surprised WebRTC doesn't at least prompt for access, similar to location, camera and similar requests.

Re: Excuse Me Sir, Your WebRTC Is Leaking

#35
post #19
post #18

Earlier quoted context omitted.

A quick heads-up: These requests do not show up in developer consoles and cannot be blocked by browser plugins I'm using FF with a WebRTC-blocking plugin, and it does successfully block the proof-of-concept exploit (it's called "Happy Bonobo Disable WebRTC", an admittedly shady name, but there are surely others).

Yes, most of those plugins were made after this test was created. This one just sets "media.peerconnection.enabled" to false in Firefox's settings. However, it means you have to disable WebRTC entirely, not just the STUN requests. Unfortunately, Chrome doesn't let you disable WebRTC at all unless you recompile with "-Denable_webrtc=0", and Chrome blocking plugins are easily bypassed (see some pull requests in my repo…

Even if you have the SafeScript and WebRTC extensions installed in Chrome? (no settings changed). That combo passed every online test I could find.

Re: Excuse Me Sir, Your WebRTC Is Leaking

#36

It seems like the problem that WebRTC wants to solve could be solved another way, by putting more of the discovery logic into the browser rather than the application. WebRTC wants to find peers on the local LAN, and communicate with them directly. Why not let the browser find peers, and then hand the WebRTC application a connection without exposing where that connection leads? That said, long-term, I think networks n…

The problem is that in order for WebRTC to work correctly for all use cases all local IPs must be sent to the remote client. One example would be if you happened to use WebRTC with two peers on the same VPN.

That doesn't necessarily mean they need to be sent to the server. The two browsers on the same LAN could coordinate via local discovery, establish a socket between themselves, hand that socket to WebRTC, and never tell the two applications running in the browser sandbox what local LAN IPs they use.

Re: Excuse Me Sir, Your WebRTC Is Leaking

#37
post #13

Earlier quoted context omitted.

I agree. For the vast majority of use cases, this doesn't seem to be an exceptionally big issue. Almost all major websites collect IP addresses and don't explicitly prompt the user that this is happening. It seems the OP is really highlighting the edge case for users who want quasi-absolute security.

Knowing the LAN IP behind any NAT is useful for silently launching behind-the-firewall cross-site attacks against the router web admin interface (or any other local services) via a browser, without having to blindly guess addresses. Someone posted a POC LAN scanner elsewhere in a thread here, too.

How many guesses would you need for typical NAT gateway LAN side IP?

I'd say two.

Re: Excuse Me Sir, Your WebRTC Is Leaking

#38
post #29

Earlier quoted context omitted.

The problem is that in order for WebRTC to work correctly for all use cases all local IPs must be sent to the remote client. One example would be if you happened to use WebRTC with two peers on the same VPN.

We have added an initial solution for this issue in Chrome 42. Users can set the following preference: "webrtc": { "multiple_routes_enabled": false }, For the location of the prefs file, see http://www.chromium.org/administrators/configuring-other-pre... . This forces all WebRTC connections to only use server-reflexive and relay ICE candidates, and only on the default IP route. While this may cause a QoS hit (two use…

Thanks very much for your reply. I've been trying to enable the preference in Google Chrome Canary on Mac OSX. However, I haven't been able to successfully block the IP leak - I suspect because I haven't configured it correctly. I had to manually create the file "/Library/Google/Google Chrome Master Preferences" and add the setting you suggested. I then reinstalled Chrome Canary and tested but no effect. I also tried editing the user preferences file in ~/Library/Application\ Support/Google/Chrome\ Canary/Default/Preference but that seems to be overwritten by the browser. How should I be configuring this preference? Thanks again.

Re: Excuse Me Sir, Your WebRTC Is Leaking

#39

I made a LAN scanner based on this in JS: http://algorithm.dk/lanscan

Very cool. I ran this on my laptop connected to my school's WiFi network and found 65 alive hosts.

You need to be very careful about what you do on other people's computers. Make sure you get permission and are able to explain what you're doing.
Post reply on HN