After playing around with some of the cool Firefox Easter eggs I had an interesting thought about the internal chrome:// resources in the Firefox web browser.
In a previous post I found that I could access local Firefox resources such as style-sheets, images, and other local content in any public web page. For example, if you’re using the Firefox web browser, you know what the following image is:
For everyone else, the above image is broken.
This is because the image is actually a link to “about:logo”. It’s a reference to a local resource only found in Firefox flavored web browsers. When the image is viewed in Chrome, Internet Explorer, or Safari, the reference doesn’t exist and the image link is broken.
Alright, how about a consolation prize – what about this image?
That may be cool, but it does beg the question – can we abuse this?
Of course we can!
Subverting Same Origin for Browser & Addon Identification
With a little bit of trickery we can use these local references to:
1. Identify Firefox with 100% accuracy
2. Identify any Firefox addons with special “chrome.manifest” settings (to be covered below)
This can be done by doing something like the following:
<img src="about:logo" onload="alert('Browser is Firefox!')" />
(Interestingly enough, this doesn’t work on the Tor browser. Perhaps due to the NoScript addon?)
The same trick can be used to identify some addons as well. For example if you are using the “Resurrect Pages” addon, you can see the following image:
Using the same tactic as above, we can enumerate the install of “Resurrect Pages” via the following:
<img src="chrome://resurrect/skin/cacheicons/google.png" onload="alert('Browser has Resurrect Pages installed!')" />
So, how do we know what addons this works for?
From the Mozilla Developer Network:
“Chrome resources can no longer be referenced from within <img>, <script>, or other elements contained in, or added to, content that was loaded from an untrusted source. This restriction applies to both elements defined by the untrusted source and to elements added by trusted extensions. If such references need to be explicitly allowed, set the
yesto obtain the behavior found in older versions of Firefox.”
To put it short, if the addon has a line like the following in it’s “chrome.manifest” file:
content packagename chrome/path/ contentaccessible=yes
When I was first investigating this behavior I thought I was original, but of course others have attempted this as well:
Oh well, let’s do it on a bigger scale!
Gathering Firefox Addon Analytics
The detection of addons is quite quick and only takes a few seconds to complete. This is due to the fact that the references are local, so they aren’t being grabbed off a webserver but directly from the browser itself. To try the scanner out in your Firefox browser, see the following link:
For other hackers or web developers, a full JSON dump of the data collected is available here (warning, big file!). This contains data on publicly accessible chrome:// URIs as well as basic information on every addon collected. I’d link to the dump of all the Firefox addon XPIs downloaded but it goes well over a gigabyte in size and I’m not sure if re-hosting addons is allowed.
Until next time,