Enrique Rando Reporter
	Description • 10 years ago

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20141126041045

Steps to reproduce:

Create a malicious webpage with an IFRAME whose SRC attribute loads another URL from the malicious server.

This new URL causes the server to respond with a "302 Found" HTTP code, redirecting to a "resource" or "chrome" URL coresponding to an addon component.


Actual results:

If the addon is installed and enabled, an error page will load in the IFRAME and the IFRAME load event WILL NOT fire.

If it is not installed or disabled, a blank page will be shown and the IFRAME load event WILL fire.

So, detecting whether the IFRAME load event fires or not enables the malicious page to find out if the addon is installed and enabled.

Please see attached file for a proof of concept. It contains 3 files:
* firefox_addons.htm -> the malicious page
* redirect.php -> Used to generate redirections
* screen_captures.pdf -> Some screen captures

To test it, just uncompress the archive in a web server directory and load "firefox_addons.php" in your Firefox browser through HTTP or HTTPS


Expected results:

There should be no difference (at least, as far as the JavaScript code cand "know") in the response depending of the status of the addon.

Resources for not installed, disabled or nonexistent addons should be treated as if they were non-contentaccessible.

	Enrique Rando Reporter
	Comment 1 • 10 years ago

I have realized that XMLHttpRequest also can be used to check for addons as it has a similar problem to the one stated above.

Redirections to a not installed, disabled an nonexistent addon resource seems to not trigger an exception while redirections to an actual resource from an enabled addon does. 

The code, using the same "redirect.php" file from previous examples, could be:

<script>
// Extensions to check
var extensions = [
	{"name":"FireShot", "url":"chrome://fireshot/content/"},
	{"name":"FireBug", "url":"chrome://firebug/content/"},
	{"name":"Down Them All", "url":"chrome://dta/content/"},
	{"name":"Download Helper", "url":"chrome://dwhelper/content/"},	
	{"name":"Skype Click to Call", "url":"resource://skype_ff_extension-at-jetpack/"},
	{"name":"Mcafee VScore", "url":"chrome://vscore/content/"}
];

var report = "";

for (var i in extensions) {
	var extension=extensions[i];
	var xhr = new XMLHttpRequest();
	xhr.open("GET", "redirect.php?url="+ extension.url, false);
	
	
	try {
		xhr.send();
	}catch(e){
		report += extension.name + "\n";
	}
 }

 alert(report);
</script>

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 2 • 10 years ago

bz, have any ideas where to start digging for this one?

	Daniel Veditz [:dveditz]
	Comment 3 • 10 years ago

reporter requested a security bounty in mail to security@

	Boris Zbarsky [:bzbarsky]
	Comment 4 • 10 years ago

So with a redirect, here's what happens.

1)  We create an nsIURI for the new URI.
2)  We create an nsIChannel for that nsIURI.
3)  We do a channel redirect notification.
4)  If the redirect is not canceled, we go ahead and do the new load.

If the chrome package is unknown, step 2 fails with NS_ERROR_FILE_NOT_FOUND, so we never reach step 3.  In the no-appcache case, that returns the error to nsHttpChannel::AsyncProcessRedirection which returns it directly to nsHttpChannel::ProcessResponse.  DoNotRender3xxBody(NS_ERROR_FILE_NOT_FOUND) seems to be false, so we go ahead and do ContinueProcessResponse.

ContinueProcessResponse has a special case to treat NS_ERROR_DOM_BAD_URI on a redirect as an error, but otherwise will go ahead and render the response body.  The description above talks about "a blank page will be shown", but presumably that's just because the 3xx response from the server didn't include any useful response body.  Otherwise, _that_ would have been shown.

In fact, you could just use script in that response body to communicate to the parent page whether it got loaded.

Anyway, in the case when the extension does exist, NewChannel succeeds, the redirect notification makes its way to the security manager, CheckLoadURIWithPrincipal is called, and if the resource is not whitelisted the redirect is canceled with NS_ERROR_DOM_BAD_URI.

So we have several options here:

1)  Change the HTTP code in necko to somehow special-case NS_ERROR_FILE_NOT_FOUND here.
2)  Change the chrome protocol handler to fail channel creation with NS_ERROR_DOM_BAD_URI
    instead of NS_ERROR_FILE_NOT_FOUND when there is no matching chrome package.  I expect
    this is one of the error cases in ConvertChromeURL; both the direct !baseURI one and
    the GetFlagsFromPackage one would probably need to be changed.
3)  Change the chrome protocol handler to allow creating such a channel but in an 
    already-canceled state so loading from it just fails in an async way.  This would
    allow us to get to the security manager check in the algorithm above.

My preference is #2 for a quick fix and perhaps #3 for a longer-term fix, because #2 introduces this weird coupling on the exact error code used.

> bz, have any ideas where to start digging for this one?

In the future, for HTTP redirect cases, maybe :mayhemer?   ;)

	Daniel Veditz [:dveditz]
	Comment 5 • 10 years ago

rating this low because it's not a security vulnerability per se, but could help an attacker know which victims to target with an add-on specific vulnerability. And of course it's a privacy/fingerprinting issue that folks trying to create anonymous browsing will be unhappy about.

	Enrique Rando Reporter
	Comment 6 • 10 years ago

Hello.

I have realized that previuos comments deal with "chrome://" URIs.

Please include "resource://" URIs too, as they can be (mis)used in the same way. In the example code they were used to detect the "Skype Click to Call" addon.

	Daniel Veditz [:dveditz]
	Comment 7 • 9 years ago

It's still a "low" severity "security" problem, but raising the severity as a lame hack to try to indicate it's bad from a privacy POV.

	Daniel Veditz [:dveditz]
	Comment 8 • 9 years ago

needinfo? on myself to investigate what happens in the resource: case. At some point we'll find out that a particular alias is not registered and fail so returning the same error might get us the desired result.

	Georg Koppen
	Comment 9 • 9 years ago

FWIW Jonas Lejon contacted us last week pointing to a PoC he had written (https://tor.triop.se/) (login with tor/tor112) checking for Tor Browser basically with

function ChkTorBtn() {
  var msg = "";
  try {
    var http = new XMLHttpRequest();
    http.open('HEAD', "chrome://torbutton/locale/aboutTor.properties", false);
    http.send();
    msg = http.status;
  }
  catch(err) {
    msg = err;
  }
  return msg;
}

So, no redirect and fancy things involved.

	Daniel Veditz [:dveditz]
	Comment 10 • 9 years ago

That's not all that page is doing to detect Tor, but yeah, you don't need redirects to detect installed chrome: or resource:

resource: is especially problematic since they are current intentionally available to <img src=>. Any package that defines a resource: alias has effectively declared that "contentaccessible=yes". Perhaps we need the ability to hide some resource: declarations from web content since many times they are for internal use. The most consistent with what we have would be to require an explicit contentaccessible=yes, but that is guaranteed to break lots of add-ons. The opposite, making contentaccessible=no available, guarantees that almost no add-ons will be that private except for a handful of the most privacy-conscious ones.

Our best hope is for WebExtensions to get the defaults right.

Anyway, Georg is right that you don't need redirects. The following code will detect installed chrome and resource packages. For chrome it's sufficient to use chrome://<pkg>/content/ and for resource you can use resource://<alias>/

function ChromeExists(url) {
  var msg='';
  try{
    var xhr= new XMLHttpRequest();
    xhr.open('GET',url,false);
    xhr.send();
    console.log("*** unexpected: no throw for "+url);
  } catch(e) {
    msg=e;
  }
  return /NS_ERROR_DOM_BAD_URI/.test(msg);
}

	Daniel Veditz [:dveditz]
	Comment 12 • 9 years ago

Maybe the answer is to make the ChromeRegister GetFlagsFromPackage() return NS_ERROR_BAD_DOM_URI for unknown packages. would that be sufficient? what tests would we break?

https://mxr.mozilla.org/mozilla-central/source/chrome/nsChromeRegistryChrome.cpp#515
https://mxr.mozilla.org/mozilla-central/source/chrome/nsChromeRegistryContent.cpp#173

For resource: it might be enough to change the return value in nsResProtocolHandler::GetSubstitutionInternal (we call this when the SubstitutingProtocolHandler has already failed to find a registered match).

http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/res/nsResProtocolHandler.cpp#70

But as I mentioned before, resource: is currently public and detectable through sub-resource checks, like an <img> tag with an onerror handler.

	Boris Zbarsky [:bzbarsky]
	Comment 14 • 7 years ago

The <img src> thing for resource should generally be fixed by bug 863246 when the addon _is_ installed.

When the addon is _not_ installed, we should check what actually happens in various cases (<img src>, redirects, direct XHR).  I recommend having separate bugs on resource:// and chrome:// here because they may need different solutions and definitely need separate code changes.

	Tom Ritter [:tjr]
	Comment 15 • 7 years ago

Hey Dan, is this issue still valid in the world of WebExtensions, or can we close this out?

	Daniel Veditz [:dveditz]
	Comment 16 • 7 years ago

It's less important in the world of Web Extensions. It's hard to guess the GUID part of a potentially-installed extension's moz-extension:// namespace, but it still applies to Firefox chrome and system addons, and especially the resources of any "Firefox-based" product like Tor Browser. Firefox chrome might be a way to distinguish different versions if you're trying to spoof what you have (though there are probably feature-detection ways to do that) and system addons might reveal if you're part of an experimental cohort or something.

	Tom Ritter [:tjr]
	Comment 17 • 7 years ago

Our understanding of this issue is that it would allow an attacker to detect that a user is using Tor Browser (by detecting Tor's default system extensions), possibly do version detection by poking at the chrome, and detect things like Test Pilot and other Mozilla-installed system extensions (hotfixes perhaps).

Based on this, anti-fingerprinting's perspective is that this is P5.