New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 64 users

Issue metadata

Status: Verified
Closed: Feb 2015
EstimatedDays: ----
NextAction: ----
OS: All
Pri: ----
Type: ----

Sign in to add a comment

Google Chrome WebRTC IP Address Leakage

Reported by, Jan 13 2014

Issue description

Vulnerability Details:
Chrome has a vulnerability whereby internal IP addresses of users can be leaked using Javascript alone without notifying the user.

Affected Versions:
Chrome Version: Version 31.0.1650.63 m + Version 32.0.1700.72 beta-m Stable + Version 34.0.1781.0 Canary
Operating System: Windows 7 Service Pack 1

Reproduction Case:
The following can be executed in the Chrome console to reproduce the test case. A self-contained HTML file has also been attached.

// create a new peer connection - dont need any stun servers for this attack to work
// adding a stun server provides the external ip address of the user as well (see HTML example)
var peer = new webkitRTCPeerConnection(null);

// create an offer object before any streams are added
// this is important because getUserMedia() requires explicit user permission
peer.createOffer(function(sdp) {
   peer.setLocalDescription(sdp, function() {
      // there seems to be a bug in the async call where the callback is called before the localDescription property has been set
      // setTimeout provides some time for the async call to finish
      setTimeout(function() {
         var sdp = peer.localDescription.sdp;
      }, 100);
}, function(err) {
}, {});

Possible Remediation Approach:
One possible approach to resolve this issue is to take the approach used by Mozilla Firefox. Firefox blocks offer creation if no streams have been added to the RTCPeerConnection object. It also does not permit the MediaStream constructors to be called directly and currently it seems that the only way to get a MediaStream is to call getUserMedia(). Currently in the case of Chrome, even if the above fix was used, an empty stream can be added using: peer.addStream(new webkitMediaStream());

Reported By: 
Jaap Karan Singh and Colin Wong, BAE Systems Detica
513 bytes View Download
Showing comments 9 - 108 of 108 Older

Comment 9 by, Jan 16 2014

Does this also defeat anonymizing proxies?
e.g. Tor?

WebRTC traffic is not anonymized by Tor; the approach recommended in previous discussions on this topic is to disable WebRTC (along with any other non-HTTP services) in builds customized for Tor.

Comment 11 by, Jan 16 2014

It sounds like this might need follow up discussion. I don't know how to address the technical challenge but many users would be unhappy to find out that Chrome exposes information about internal network topography to external websites.
This has been discussed a fair amount in the webrtc community, albeit with no silver bullets, as mentioned in, S 5.4 and, S 4.2.4

Happy to discuss more.

Comment 13 by, Jan 17 2014

Labels: Cr-Privacy Cr-Enterprise
Nice to see the spec drafts acknowledge the problem, even if they don't have any solution. :/

Adding Privacy and Enterprise flags to this bug, since this really falls more into their domain than Security.
Project Member

Comment 14 by ClusterFuzz, Jan 18 2014

Labels: -Untriaged-1 Untriaged-2

Comment 15 by, Jan 20 2014

Project Member

Comment 16 by ClusterFuzz, Jan 21 2014

Labels: -Untriaged-2 Untriaged-3
Labels: -Untriaged-3
Status: Assigned
If I remember correctly, the IP snooping is gated by the user granting access to the camera. Is this correct?
It's not directly gated by the camera access. There are one-way media and p2p data cases where the user is not required to consent to media access because their camera and/or mic is never needed.
Dominic: is the scenario described in c#18 a privacy concern? This bug is not really a security bug.
Labels: -Restrict-View-SecurityTeam -Type-Bug-Security -Security_Impact-Beta -Security_Impact-Stable -Security_Severity-Low
Summary: Google Chrome WebRTC IP Address Leakage (was: Security: Google Chrome WebRTC IP Address Leakage)
Removing from security queue, implemented as per the spec. Privacy/Enterprise people, do you care about this?

Comment 22 by, Sep 24 2014

Labels: -Cr-Blink-WebRTC Cr-Blink-Webrtc-Network
Here is a public demo of this leakage in action:

I'm not too familiar with the spec, but could the user agent wrap local IP addresses to avoid ever exposing an IP directly to the code running on the web?  It's not clear to me why revealing any IPs directly is necessary.

Relevant source on

var RTCPeerConnection = /*window.RTCPeerConnection ||*/ window.webkitRTCPeerConnection || window.mozRTCPeerConnection;
    var rtc = new RTCPeerConnection({iceServers:[]});
    if (window.mozRTCPeerConnection) {      // FF needs a channel/stream to proceed
        rtc.createDataChannel('', {reliable:false});
    rtc.onicecandidate = function (evt) {
        // convert the candidate to SDP so we can run it through our general parser
        // see for details
        if (evt.candidate) grepSDP("a="+evt.candidate.candidate);
    rtc.createOffer(function (offerDesc) {
    }, function (e) { console.warn("offer failed", e); });
    var addrs = Object.create(null);
    addrs[""] = false;
    function updateDisplay(newAddr) {
        if (newAddr in addrs) return;
        else addrs[newAddr] = true;
        var displayAddrs = Object.keys(addrs).filter(function (k) { return addrs[k]; });
        document.getElementById('list').textContent = displayAddrs.join(" or perhaps ") || "n/a";
    function grepSDP(sdp) {
        var hosts = [];
        sdp.split('\r\n').forEach(function (line) { // c.f.
            if (~line.indexOf("a=candidate")) {     //
                var parts = line.split(' '),        //
                    addr = parts[4],
                    type = parts[7];
                if (type === 'host') updateDisplay(addr);
            } else if (~line.indexOf("c=")) {       //
                var parts = line.split(' '),
                    addr = parts[2];

Comment 25 by, Oct 30 2014

Any wrapped IP would need to be able to be unwrapped by the remote side, so that it can try a connection to the source IP. Therefore, I don't think the wrapping would have any strength.

As to why the web page needs to see the IPs, the IPs are handed to JS to be sent out of band to the remote side.
Yes, the only protection this adds is preventing web pages from seeing local IPs.  The IPs would still be visible to other browsers.

Could you expound on why the web page needs to see the IPs?  i.e., why is sending the IP out of band important?
There is no in-band mechanism that can be used.
Sorry, but why is that?  I may not understand your usage in-band vs. out-of-band in this context.

Here are my assumptions:
1) Any local IP address obtained by a web page is only used to establish connections to that IP address.
2) All connections established by a web page are established by the user agent on behalf of the web page.

So if the user agent encodes local IP addresses before handing them to the web page, it could decode them before establishing a connection.

Is one of these assumptions wrong?  Or is my logic flawed?

I take "no in-band mechanism ... can be used" to mean that assumption 2 is incorrect.
The local IP address is communicated to the remote side so that the *remote* side can connect to you. The remote side needs to be able to get a raw IP address (for you) somehow.
I don't think there's immediate action required from an enterprise perspective, but we may want to consider adding a policy setting for admins to adjust behavior of WebRTC as needed and/or restrict WebRTC usage to whitelisted web origins only.

Comment 31 by, Oct 31 2014

re #29: I'm unfamiliar with the protocol used to send the local IP over.  Is it app-specific? It seems that the IP could be communicated to the remote server by the browser, still only exposing the web page to an encoded version of the IP.
reddaly: Communicating the IP to the remote peer is left to the app.  WebRTC does not specify a client-server signalling protocol.  On the web, the server and the app typically represent the same entity, so there is little incentive to conceal info from one but reveal it to the other.

However, if you're interested in efforts to change the treatment of local IP addresses, you might like, which describes a way to give users more control over WebRTC routing.
We have also suggested a local policy setting that could restrict the use of internal IPs. This could have downsides (i.e. in intra-enterprisde communication if the corp NAT is not set up for hairpinning) so it's not something we would want to turn on by default.

Comment 34 by, Nov 25 2014

Labels: WebrtcTriaged
need a fix
Why not prompting the user for permit when any webrtc functions are used for the first time that reveal local IP addresses? Similiar like the user is prompted already today when accessing local media sources? 
Because in general we don't want to prompt users with questions they are ill-equipped to answer. The number of end-users that understand the difference between their local IP and the global IP visible to the outside world is very small so they have no context by which to make an informed decision.

Whereas people in general understand the difference between "playing a media stream from the internet" vs "playing a stream from a file on their device".

On the enterprise side, we have not heard of any concerns over this, and in general enterprises have ample resources (proxies, firewalls, etc) to restrict which WebRTC endpoints their users can access. I don't see any further action required on the enterprise side.
What is around now known as "hack" is the code already mentioned above,
There no media sources are used, therefore no user prompt comes up currently.

For real webrtc audio/video application cases, both the use of media sources and the gathering of local IP address is needed, so by making a combined prompt and user grant, like "Are you willing to allow access to your microphone/camera and to reveal your private IP address to the site ..." the user will not get more prompts than now, and nobody can say then that webrtc reveals private data without user consent.  
That will prevent uptake of data channel applications.

Generally, I don't think questions regarding IP addresses are things that we can expect users to answer properly.

The current concerns regarding this issue are mostly focused around sites detecting the ISP public IP address in VPN situations, which I think is a different problem from what is being discussed here (i.e. the private address is not the concern).
This issue means a user prompt is required for all WebRTC apps to be enabled.

You've got users on VPNs out there and this issue automatically exposes both their private and public IPs.

The right thing to do is as Martin said in #38: a combined prompt.

Comment 41 by, Feb 12 2015

We are investigating various solutions at the moment.
Project Member

Comment 42 by, Feb 19 2015

The following revision refers to this bug:

commit 7c98bab02128ae9fdc4fcc9a9df38588af86290e
Author: guoweis <>
Date: Thu Feb 19 14:54:51 2015

Add a Preference to allow WebRTC only bind to "any address" (all 0s). This way, no local IP or private ISP's public IP leaked when VPN is the default route.

Add webrtc.multiple_routes_disabled preference to RendererPreferences. Default is false. When set to true, a new port allocator flag will be passed to P2PPortAllocator which will have WebRTC only bind to all 0s (any address) IP and the default route will be used as how chrome/http is routed.

Each rtc_peer_connection_handler is associated with a WebFrame and it leads to a webview and then the mapping RenderViewImpl which has RendererPreferences that we care.

The corresponding webrtc change is at

BUG= 333752 

Review URL:

Cr-Commit-Position: refs/heads/master@{#317047}


Comment 43 by, Feb 19 2015

The way to test this change is to copy the following into preferences file

"webrtc": {
 "multiple_routes_enabled": false
The extension change is also landed by
Status: Fixed
Note that with this preference change, along with the extension, private IP along with non-default public IP will be hidden.

Private IP will be filtered out. Non-default public IP simply won't be discovered as the binding is done to "any" address (all 0s), routing should just behave like http.
I'm not sure I understand the fix. Can someone dumb this down a bit?

- Why isn't this preference set to true by default?
- What does "non-default" mean in reference to "non-default public IP"?

Comment 47 by, Feb 19 2015

This change causes WebRTC traffic to be forced through the same path that HTTP traffic would, i.e. the traffic follows the default route to the destination site. As a result, the only IP that can be discovered is the IP that the remote site could already learn from HTTP traffic.

It's not on by default at this time because it has implications for quality-of-service; it may force WebRTC traffic to take a suboptimal routing path, e.g. calls on a company intranet may be forced to go outside the company and then be hairpinned back in.
I see, so my understanding now is that instead of being P2P, this setting makes traffic go through a middleman (the middleman being the host providing the WebRTC service?).

That seems like a sub optimal fix, or at least incomplete.

Users have to know to turn on this setting. This fix doesn't address that issue. Most users who are behind VPNs will therefore still be affected by the problem.

A simpler fix would be to simply prevent WebRTC from being enabled without prompting from the user.

Comment 49 by, Feb 19 2015

Sorry for being unclear. The WebRTC traffic will go through the same local IP used for HTTP traffic, e.g. the VPN if one exists and is the default route. It will not go to the web server.

Many users on VPNs (e.g. corp VPNs) will want to use WebRTC even while VPNed. This solution allows these users to force all WebRTC traffic through the VPN, if desired. The 'prompt' solution would not solve that situation.

We will of course continue to evaluate and refine this solution. Getting a workable v1 solution was a top priority for Chrome 42.
> The WebRTC traffic will go through the same local IP used for HTTP traffic, e.g. the VPN if one exists and is the default route. It will not go to the web server.
> Many users on VPNs (e.g. corp VPNs) will want to use WebRTC even while VPNed. This solution allows these users to force all WebRTC traffic through the VPN, if desired.

I see, thank you for that clarification.

> The 'prompt' solution would not solve that situation

Right, but it would address the privacy issue in the default case, which is the primary concern. This fix doesn't (yet) do that. Users have to be aware of this setting, understand what it does (less than 1% probably), and then they will experience degraded QoS.

On the other hand, the prompt preserves QoS, and protects all users by default.

Comment 51 by, Feb 19 2015

I think the prompt is suboptimal as well, since to non-technical users it's very unclear what "do you want to allow this site to use WebRTC" really means. We don't ask users about whether they should allow XHR, IMG downloads, font enumeration, etc.

However, as mentioned above, we'll keep thinking about this.
> to non-technical users it's very unclear what "do you want to allow this site to use WebRTC" really means.

Agreed, so that's why an easier to understand message would be helpful. I'm sure the Chrome team can come up with a great one.

It's really not anything special to prompt the user to allow features that could impact privacy. Apple does this *constantly* on iOS for things like GPS, Contacts, Calendar, and Photos access, as well as notifications.

And that's a big reason why I and many people choose iOS btw.

At the same time, users feel empowered, not encumbered, by the fact that they can choose what information they share.

So, something like: "This webpage is requesting access to your public and private IPs for its functionality, Allow/Deny?"

> However, as mentioned above, we'll keep thinking about this.

Awesome. Well, in that case I would also consider marking this as still unresolved, since it's not resolved for most of your users.

Comment 53 by, Feb 19 2015

I understand your point, but my understanding is that on iOS right now, an application can do whatever it wants on the network without asking the user.
> I understand your point, but my understanding is that on iOS right now, an application can do whatever it wants on the network without asking the user.

There is precedent even in the case of Safari, where users get prompted if an HTML5 app wants to know the user's location.

Comment 55 by, Feb 19 2015

That is the HTML5 Geolocation API; Chrome prompts as well when that API is used.
the preference name in comment #42 is "multiple_routes_disabled", but in comment #43 is reads "multiple_routes_enabled", which is correct or both of them are Ok? Thank.

Comment 58 by, Feb 20 2015

apologize for the inconsistency. #43 was right. It's "webrtc.multiple_routes_enabled". I also modified the description in the Issue 916873004 to reflect this.
Labels: M-42
As a non-technical user of chrome ( but knowledgeable in IT in general) I just want to say that my concern about this issue has found me in this forum ( where I have never been before, or needed to be). If I am here, many others are seriously concerned about this, and wondering: why the hell dont you do something about it?

I have not read that much of the forum, but to find out this issue is being discussed in terms of, and I summarise ' Users wont understand, therfore maybe we shouldnt do anything' is disgusting.

Sorry for my annoyance, I just think this should have been blocked immediatley and users informed. BAHH!!!!!

Comment 61 by, Feb 25 2015

Your suggestion that we didn't do anything is inaccurate. We did do something about it; we gave users a way to force WebRTC traffic through their VPN in Chrome 42. 

See comment #43 for how to set this setting.

Comment 62 by, Feb 25 2015

Note to #60: This is not a forum, this is a bug tracker.
The forum is the mailing list discuss-webrtc - see!forum/discuss-webrtc for details.

 Issue 457492  has been merged into this issue.
Copied here from  Issue 457492  to CC folks:

> This is a dup to 333752 which has been fixed in M42.  Please see that bug for details.

The OP's concern has not been addressed in 333752.

My understanding is that 333752 provided a custom option to force traffic through VPN. That doesn't address this issue for multiple reasons:

1. OP asked for a setting in "chrome settings", not an invisible option.
2. OP asked to be able to disable WebRTC. This has not been offered here or in 333752.

Please unmark this as "fixed" or "duplicate".
Can someone make #43 more clear so that all users would know how to change this setting if desired? Like a step-by-step.
This issue is not fixed for a couple reasons (at least):

1. Users are placed in danger by default (see: )

2. Possibly in all cases (but certainly in ordinary browsing), a user's private IP is still leaked. In a targeted attack, information about the internal local area network topology can be very relevant, which is one of the reasons why it should be treated as private information.
Status: Verified
For #65:
1) Go to chrome://version/, find the directory listed in "Profile Path"
2) Close all instances of Chrome. This is *important* because Chrome regularly updates the Preferences file while Chrome is running, and you need that file to be in a static state in order for changes to stick (and to avoid possible file corruption).
3) Use your OS's file manager to navigate to the Profile Path
4) Copy your existing Preferences file (in case something goes wrong during editing)
5) Open the Preferences file for editing
6) At the bottom of the file, before the final closing bracket, make these two changes:
6a) add a comma to the last existing entry
6b) add
   "webrtc": {
      "multiple_routes_enabled": false

For example, the last few lines of my Preferences now look like:
   "translate_whitelists": {

   "webrtc": {
      "multiple_routes_enabled": false

7) Save the changes to Preferences and reopen Chrome
8a) If you immediately see an error about profile corruption, close Chrome, restore your Preferences from backup, and edit that file again. In my experience, the Preferences file seems sensitive to the presence/absence of commas. (Please don't put complaints about Preferences parsing in this bug)
8b) If you don't see an error about profile corruption, then you're good to go. Proceed with any relevant IP address tests.

For #66:
Based on my testing and the fact that  bug 457492  has been reopened for to possibly provide a simplified solution, I'm closing this bug.

For anyone else:
a) If you have problems using the multiple_routes_enabled Preference, please file a new bug. Be sure to include the exact text of the "webrtc" section of your Preferences file, along with repro steps.
b) If you're interested in future plans, please star  bug 457492 .
c) If you have suggestions for other ways to address this issue in future releases of Chrome, please post to the public discuss-webrtc group (!forum/discuss-webrtc)
This solution does not work.....

The end of my prefernce files reads:

   "translate_accepted_count": {
      "de": 1,
      "es": 0,
      "fr": 1,
      "lt": 1,
      "ru": 0
   "translate_blocked_languages": [ "en" ],
   "translate_denied_count": {
      "de": 0,
      "es": 2,
      "fr": 0,
      "lt": 0,
      "ru": 1
   "translate_last_denied_time": 1422920008040.3,
   "translate_site_blacklist": [ "" ],
   "translate_too_often_denied": true,
   "translate_whitelists": {

   "webrtc": {
      "multiple_routes_enabled": false
   "zerosuggest": {
      "cachedresults": ""

VPN enabled, and My public IP address is still revealed.

I am shocked at the attitude taken towards this serious breach in security by a google endorsed product.  

This is an issue even after the latest chrome update, GRRRRRRR
To understand the issue, could you post the result from this url with and without this preference?
This will help to understand what is going on here.
You also need to test it at . Sometimes the link given in #69 gives nothing while still manages to get the actual IP through webRTC.
I also strongly agree that this issue needs to be taken more seriously. At least there should be an option in advanced settings (such as chrome://flags) to prevent the IP leak like in Firefox.
I just tried and it did not detect my location while connected via vpn.  It just reported the same IPs as the link in #69 does.

tonytan980: what version of Chrome are you using to test this? is tracking adding a Chrome flag/option to control this.
#67...I do NOT accept this as a viable solution for anyone but the most technically advanced. There needs to be a flag or some other "switch" available to users or support is going to be a nightmare. 
#74: yes, see  bug 457492 


reveal my Public IP with the 

 "webrtc": {
      "multiple_routes_enabled": false

Flag set.

There is no point in posting the results, they are identical.

Chrome version : 41.0.2272.76 m
Chrome 41 predates these changes. Could you try Chrome Beta or Chrome Canary? (i.e., Chrome 42)
Ok, thanks. I updated to 43.0.2326.2 canary (64-bit)

added the code to the end of my preferences file

And IP does not leak on iptest,net or

when using a vpn.

However, that may work for me... what about the millions of people who do not look for this sort of solution or do not even know about the problem?  I am still pretty shocked to find this sort of problem only has solutions available to those who keep asking and digging *sigh*

Regardless, many thanks for giving me a solution.

Comment 79 by, Apr 23 2015

The test is outdated. Current chrome (42.0.2311.90), even with the WebRTC extension installed, shows the real IP when you visit the up to date test:
The extension is outdated, too. You need to change your Chrome preferences
file to prevent WebRTC IP leaks. Please see the earlier comments.
El 23/4/2015 12:26, <> escribió:

Comment 81 by, Apr 24 2015

re #79 - please be precise - does show different addresses for the first and second IP addresses detected?

If the addresses are the same, the site detects no WebRTC problem (the first address is revealed by HTTP, not WebRTC). If they're different, the configuration is of interest.

Comment 82 by, Apr 24 2015

With the WebRTC extension installed (, the test and do not show the real public IP.

But shows the real public IP and the VPN IP, even with the extension installed. I read somewhere what this test does differently from the others that enables detection. It has to do with creating a new iframe on the fly or something similar. I can try to hunt it down.

Now that I've applied the mitigation ( to standard Chrome 42 (not canary) no tests AFAIK can detect the real IP.

From the last link above: "Long term the ideal solution would be to have a user prompt whenever a WebRTC connection is being requested. This would be similar to the prompt requesting a user to authorise access to the camera and microphone." In other words, ask the user if it is OK to reveal to the website your real IP. (feel free to ignore this part: it might be possible to bypass the question if it can be determined that the user's ISP public IP is being broadcasted or when the WebRTC request is coming from within the LAN.)

Comment 83 Deleted

Comment 84 by, Jun 10 2015

#67 does not solve this bug on Chrome 43.0.2357.124.

I've opened  bug 497040  because of this.
 Issue 506730  has been merged into this issue.
 Issue 509430  has been merged into this issue.
FYI: uBlock Origin now has an option to prevent webrtc ip leakage:

Seems to be working properly (but it does break certain things for me, like twilio integrations on certain sites).

Comment 89 by, Jul 15 2015

Even with that uBlock Origin option enabled, your non-proxy WAN IP is leaked if you're using a SOCKS proxy.
#88: could you post a link to a broken site? That is one of the things we are trying to avoid.
#89: that issue is being tracked in  bug 497040 .
#90: The one I'm having trouble with now is ClearSlide conference calling (using twilio). 
Test it out here: 
Click "dial in" at the top, enter 8242-9078 for the access code.

Before enabling the webrtc blocking option on uBlock Origin, dial in works and says "you will now be added to the conference".

When I enable the option, the dial in doesn't work (it makes the chime noise, but then nothing).

Feel free to test out, but try to not use all my conference calling minutes ;-)

Comment 92 by, Jul 17 2015

I can repro #91 scenario now and this seems like a bug. I'll be working on this. The credential you provided helped me repro this. 

Comment 93 by, Jul 22 2015

created webrtc  bug 4865 to track issues in #92

Comment 94 by, Jul 27 2015

ok. found the issue. The problem that the stun port in this case ( never has any candidate such that it is never PortReady hence doesn't start to listen.
I think in this case we would probably want to go immediately to PortReady if we have no STUN server. Or maybe we would always go to ready as soon as the bind succeeds.

Comment 96 by, Jul 27 2015

I am thinking we should generate candidate in this case (and filter it out later if we have turn/stun specified). 

Comment 97 Deleted

@83 try the "Official" WebRTC Network Limiter extension created by Google ( )
 Issue 567453  has been merged into this issue.
Issue 768706 has been merged into this issue.
Hi, may we know if installation of the extension is the only way to stop this behavior? Any answer will be very much appreciated. 
This issue was resolved in 2015. Chrome follows the recommended behavior in
Note that "Chrome follows the recommended behavior" translates to: "In the default configuration Chrome leaks local IP addresses."

If this is undesired, an extension may be used to change the configuration.
That aspect is discussed in detail in I would be happy to go over the document's findings and reasoning with you.
Yes, it's all in the draft. Still I consider it useful to spell out what "recommended behavior" means so that readers of this bug don't have to dig through the doc.
 Issue 813119  has been merged into this issue.
Issue 834974 has been merged into this issue.
Showing comments 9 - 108 of 108 Older

Sign in to add a comment