1272383 - Enumeration/detection of add-ons using synchronous XMLHttpRequest and chrome URIs

Status: RESOLVED DUPLICATE of bug 1120398

(Core :: Security, defect)

Description

[Iskander S.]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.80 Safari/537.36

Steps to reproduce:

All Firefox versions/editions (Firefox for mobile, Firefox Developer Edition...) and all browsers based on them that support add-ons are vulnerable to enumeration/detection of add-ons.

Making a XMLHttpRequest to chrome://[add-onID]/[fakePath] (for example chrome://firebug/content/Firebug.png) and encapsulating the invocation in a try-catch block, can be used to know if an add-on is installed.

PoC code:

try{
  var xmlHttp = null;
  xmlHttp = new XMLHttpRequest();
  xmlHttp.open( 'GET',add-onURL, true );
  alert('Add-on Installed');
  return xmlHttp.responseText;
}
catch(err){
  alert('Add-on Not Installed')
}


Actual results:

When the add-on is not installed, an exception is raised. By knowing that, it is easy to check if multiple add-ons are installed with 100% accuracy.

This data can be used for various purposes:

The inclusion of user's installed add-ons enhance the uniqueness of device fingerprinting techniques and analytics (for instance for Panopticlick from EFF: https://panopticlick.eff.org/).

All the information collected can be used for targeted attacks (malicious actors can know the users' concrete usage of a computer: used products and services, their interests, and so on). This information can be used to develop a targeted exploit kit: depending on the result of the enumeration, the website can decide to trigger the malicious payload, or even to use different malicious payloads depending on the data. One example would be the case of Crossfire, presented in NDSS 2016 and Black Hat Asia 2016 (http://www.onarlioglu.com/publications/ndss2016crossfire.pdf, https://www.blackhat.com/docs/asia-16/materials/asia-16-Buyukkayhan-Automated-Detection-Of-Firefox-Extension-Reuse-Vulnerabilities.pdf).

Installed add-ons can also be utilized by an attacker to increase the information about the victim in order to carry out (automatic or not) social engineering  attacks. This information can be used in several ways to deceive users, posing as legitimate messages from a particular extension and leading users to perform a pernicious action. For example, the attacking website discovers that the user's browser has a password management add-on installed, then the attacker tries to deceive the user asking to the password again to steal it. 


Expected results:

The solution/fix for this problem is to disable that exception.

Comment 1

[:Gijs (he/him)]

Firebug is a bit of a bad example because it sets contentaccessible=true, so that's its own fault.

For everything else, both things should do the same (ie silently produce empty strings etc.) but don't. Not sure why off-hand.

Also not sure this needs to be kept security-sensitive considering e.g. bug 1143318 is public and it seems that for non-webextensions this is a battle we might just have lost by now. I think add-on SDK add-ons use resource:/// URIs, which makes them vulnerable to the public bug 1143318 already. :-\

Comment 2

[Kris Maglione [:kmag]]

Agreed, this is a well-known problem. It doesn't need to be a security bug.

Also, this is basically the same bug as bug 903959.

Comment 3

[:Gijs (he/him)]

(In reply to Kris Maglione [:kmag] from comment #2)
> Agreed, this is a well-known problem. It doesn't need to be a security bug.
> 
> Also, this is basically the same bug as bug 903959.

This was filed about chrome:// URIs, and seems to work even when add-ons don't set contentaccessible=yes . In principle, that's a bug, and it seems bug 903959 comment #1 wouldn't have expected this to work - but it does. Most everything in that bug seems to imply the issue is about resource:// URIs. It may still be valuable to fix chrome:// URIs. But I can't see the deps of that bug, so maybe this is already a dupe of those?

Comment 4

[Kris Maglione [:kmag]]

Hm. OK, so there are two issues here. The one reported in comment 0 is that contentaccessible resources load successfully when the add-on is installed, but not otherwise.

The other is that, similar to bug 1143318, attempting to load a chrome: URL reports a different error depending whether the chrome package is registered and not allowed (NS_ERROR_DOM_BAD_URI), or not registered at all (NS_ERROR_FILE_NOT_FOUND).

That does seem like a separate issue, that we should fix. I still don't think this needs to be a private security bug, though.

Comment 5

[:Gijs (he/him)]

(In reply to Kris Maglione [:kmag] from comment #4)
> Hm. OK, so there are two issues here. The one reported in comment 0 is that
> contentaccessible resources load successfully when the add-on is installed,
> but not otherwise.
> 
> The other is that, similar to bug 1143318, attempting to load a chrome: URL
> reports a different error depending whether the chrome package is registered
> and not allowed (NS_ERROR_DOM_BAD_URI)

I don't see this, FWIW. With Chrome List ( https://github.com/gijsk/chromelist/blob/master/chrome.manifest - not contentaccessible, https://addons.mozilla.org/en-US/firefox/addon/chrome-list/ ) installed, doing:

  var xmlHttp = null;
  xmlHttp = new XMLHttpRequest();
  xmlHttp.open( 'GET', "chrome://chromelist/content/firebug.png", true );

(nb: file does obviously not exist!)

from a content page gets me no exceptions at all.

Comment 6

[Kris Maglione [:kmag]]

I get an error on .open() if I reference a chrome package that doesn't exist, and on .send() if I reference one that does, whether or not the file in that package exists (and whether or not the request is async).

Comment 7

[:Gijs (he/him)]

(In reply to Kris Maglione [:kmag] from comment #6)
> I get an error on .open() if I reference a chrome package that doesn't
> exist, and on .send() if I reference one that does,

Ah, right, OK, but that's still different behaviour that the web can pick up on, as per comment #0... I guess the different error messages aren't really any better, even if they both happened for open(). We should really never be exposing XPCOM error messages to the web, but there we are. The contentaccessible stuff is the only reason we can't just make any chrome:// URI fail, but we should probably make all the non-contentaccessible stuff (existing or otherwise) fail the same way on open()...

Comment 8

[Iskander S.]

In my humble opinion, I think it should be a private security bug until fixed, because it could be used for malicious targeted attacks, device fingerprinting or analytics (as indicated in comment #0). One example is using the obtained information to generate automatic working malicious payloads for Crossfire (presented in NDSS 2016 and Black Hat Asia 2016:(http://www.onarlioglu.com/publications/ndss2016crossfire.pdf, https://www.blackhat.com/docs/asia-16/materials/asia-16-Buyukkayhan-Automated-Detection-Of-Firefox-Extension-Reuse-Vulnerabilities.pdf).

Comment 9

[Daniel Veditz [:dveditz]]

(In reply to :Gijs Kruitbosch from comment #3)
> This was filed about chrome:// URIs, and seems to work even when add-ons
> don't set contentaccessible=yes . In principle, that's a bug, and it seems
> bug 903959 comment #1 wouldn't have expected this to work - but it does.
> Most everything in that bug seems to imply the issue is about resource://
> URIs. It may still be valuable to fix chrome:// URIs. But I can't see the
> deps of that bug, so maybe this is already a dupe of those?

Yes, this appears to be a dupe of bug 1120398 comment 1, which may or may not need an additional fix for chrome: after bug 903959 is fixed for resource:.