Adblock Plus and (a little) more
Web pages accessing chrome:// is forbidden · 2008-04-13 22:30 by Wladimir Palant
I didn’t believe that this would still be fixed in Firefox 3 but bug 292789 has landed. The timing could be better, having such a big change go in shortly before a release is certainly less than optimal — yet still, I think that we are much better off now than we were before.
Until now any web page could load scripts or images from the chrome:// protocol — files that are meant to be used by the browser itself. So as a web page you can write:
<script src="chrome://browser/content/browser.js"></script>
And that will load the script actually in use by the Firefox browser. I have seen many bogus vulnerability reports about this feature but it isn’t an issue in itself: just because you can include a browser’s script in your web page, it will not execute with browser’s privileges. The effect will be exactly the same when you take this file from some Firefox installation and upload it to your website, the script will have the same privileges that your site has. The files available via chrome:// protocol are exactly the same in each Firefox installation, and by reading them you don’t gain any information you couldn’t get by other means.
Well, almost no information. Thing is, extensions will add new files that will also be available via chrome:// protocol. So a web page could use this code:
<img src="chrome://adblockplus/skin/adblockplus.png">
And that image would only load if Adblock Plus is installed. As some people noticed, this is a nifty way to detect which extensions a site’s visitor has installed. And, obviously, when I browse the web I don’t want everybody to know what I use, in particular because that would allow targeted attacks at vulnerabilities in extensions. I designed a workaround – but it is used only by Adblock Plus and a bunch of other extensions.
Nice to see that Firefox fixes this issue now. In the new world, only chrome://browser/ and chrome://toolkit/ are accessible from the web (these are the files we want to be accessible). Everything else (including extensions) is hidden however. If for some reason an extension needs its files to be accessible from the web, it can specify the flag contentaccessible=yes in chrome.manifest — but that should be a rare exception.
There is a catch however. Firefox 2 does not understand the flag contentaccessible=yes and will ignore the entire line. If your extension should be backwards compatible, something like this will work for both Firefox 2 and Firefox 3:
content mypackage location/
content mypackage location/ contentaccessible=yes
I expected to use this for Adblock Plus (temporarily at least) because of the “object tabs” feature, but surprisingly it wasn’t broken. Good for me.
Comment [11]
Commenting is closed for this article.
BenoitRen · 2008-04-14 00:10 · #
“In the new world, only chrome://browser/ and chrome://toolkit/ are accessible from the web (these are the files we want to be accessible).”
Why, pray tell, do we want them accessible from the web?
Ancestor · 2008-04-14 00:40 · #
BenoitRen, they are necessary for remote XUL applications. Much of XUL would be broken when used in unprivileged documents without access to those scripts.
Philip Taylor · 2008-04-14 04:33 · #
Just out of interest, I had a look at how chrome:// seems to be used in the wild. Out of about 130K of the pages listed on dmoz.org, I found:
http://www.hypno-analysis.co.uk/ and http://www.treesculptor.co.uk and http://www.stjohnsgerman.com (a few months ago, now changed) – chrome://editor/content/images/tag-comment.gif (which seems to come from Nvu, along with the quite bogus <comment> element)
http://www.laurencejgillis.com/ and http://www.kleinbahnsammler.at/ and http://www.sdw.pl/ – chrome://skype_ff_toolbar_win/content/inactive_ln.gif and some similar others
http://www.psychotherapy.ro and http://www.uwm.edu.pl – chrome://piclens/content/launch.png
http://orangeloop.bravehost.com – chrome://searchstatus/skin/nofollow.css
http://www.bienen-partner.de – chrome://noscript/skin/icon32.png
http://mendocinohotel.com – chrome://informenter/skin/marker.png
(These all look like mistakes to me, rather than attempts to actually do anything useful with chrome://)
Reply from Wladimir Palant:
Yes, all of these look like copy&paste of HTML code that was modified by extensions. However, I have seen code in GMail using chrome:// URLs to detect extensions. It seems that they just forgot to remove some experimental code because the result was never used but still.
Pavlos · 2008-04-14 09:29 · #
Yep, great timing.
Any reason why file:/// urls are also forbidden from accessing the content?
Reply from Wladimir Palant:
Any reason why file:/// URLs should have more privileges? Most of the time they are the same web pages saved to your disk. From what I understand, the tendency is to restrict file:/// URLs rather than give them additional privileges.
Pavlos · 2008-04-14 11:00 · #
Here’s an example from my extension:
The stylesheet service requires a URI to load a stylesheet. My extension generates the css dynamically, saves it to a temp file and uses the stylesheet service to load it from there. The CSS uses xbl bindings and images found in my extension’s chrome. It doesn’t work as-is anymore.
Anyway, this change may have broken it but it works with contentaccessible=“true”. The problem is that I don’t have the option to allow access to the content from file:/// urls while restricting access from the web. If file:/// urls where able to access it then I wouldn’t have to add contentaccessible=“true”, exposing the extension’s presence. Another option would be to have contentaccessible accept protocols instead of a simple yes/no; something like: contentaccessible=“file,data”.
By the way, contentaccessible doesn’t seem to work for “skin” registrations, only for content.
Reply from Wladimir Palant:
Yes, you cannot have a distinction between http:// and file:///. You can only put your stylesheet in some chrome:// namespace, then it would be able to access your images without contentaccessible.
Just checked this, contentaccessible=yes will only be accepted for the content declaration but will have effect on skin and locale as well. I commented on this in the bug, it should be important for the documentation.
David DeWinter · 2008-05-18 19:06 · #
Good article, Wladimir. Really appreciated the tip on making extensions backward-compatible while still allowing FF3 to access the chrome URLs from the extension.
Johan · 2008-05-20 15:07 · #
Do you know why the “object tabs” feature wasn’t broken for you?
Reply from Wladimir Palant:
Because in case of “object tabs” chrome code calls addBinding – so the principle checked is a chrome principle and not the principle of the document where the binding is loaded. If you would use -moz-binding CSS property instead of addBinding, that would break with the new restrictions of course.
guest · 2008-05-21 11:39 · #
Dear Mr. Taylor, I too “looked to see how this is being used in the wild”
javascript +“chrome://”
http://www.google.com/search?hl=en&q=javascript+%2B%22chrome%3A%2F%2F%22
and immediately found, upon PAGE ONE of the search results, an example which demonstrates exploitation of the chrome vulnerability. I’m suspect the script kiddies are happily putting this to use.
http://www.gnucitizen.org/blog/0day-quicktime-pwns-firefox/
Anthony · 2009-01-04 02:44 · #
I understand the security issue, but what if the chrome code itself wants to add a chrome image as a background for an element in the page. Is this possible? Thanks!
abdulhaq · 2010-04-10 20:35 · #
Interesting that gmail references chrome://, some time ago I got a warning from gmail along the lines of ‘firebug prevents gmail from running smoothly, it is recommended that you disable firebug for gmail’
Reply from Wladimir Palant:
Yes, see my reply to comment 3.
Susan · 2010-11-09 04:48 · #
I have homework to and this is really effecting all the websites that my school uses to access homework…im unsure of what exactly it is but I wish it never came about.
Reply from Wladimir Palant:
Wow, this cryptic message must be coming from a sphinx. I am honored!
Ok, seriously – what are you talking about? I have a “slight” suspicion that your comment has absolutely nothing to do with the blog post you are commenting on.