308808 - Web pages can detect which extensions are installed (CheckLoadURI call for <script> allows chrome: URLs)

Status: RESOLVED DUPLICATE of bug 292789

(Core :: Security, defect)

Description

[Jens Bannmann]

The HTML <script> element does not do any URL checks before loading a script.
This results in regular web pages (from http://) being able to successfully load
scripts from chrome://. The chrome scripts lose their privileges, of course, but
it is a simple matter of |"functionname" in window| to detect whether the script
was available and loaded. Worse, |var source = "" + functionname;| returns the
implementation of a function, which enables the web page to do a more
fine-grained distinction across application or extension versions.

This is probably not a security bug in itself, but I'd classify it as an
unwanted information leak that makes targeting exploits easier. When a security
hole is discovered in an extension, it is easy for the attacker to only activate
the exploit on systems where the extension is installed.
Other potential uses are keeping out "unwanted" AdBlock or GreaseMonkey users
from web sites - sure, they can disable JavaScript for web pages, but to enjoy
the web most users won't do that, and "crossing" the web<>chrome barrier in this
way shouldn't be possible from the start.

Testcase coming up.

Comment 1

[Jens Bannmann]

Attachment: testcase / demo

Simple demonstration page detecting the presence of GreaseMonkey, IE View,
FlashGot and Mouse Gestures.

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

for extensions that ship their own interfaces, webpages can also check for if
("nsIFoo" in Components.interfaces) to detect them...

Comment 3

[Jesse Ruderman]

<script> must be doing some kind of CheckLoadURI, because a src attribute with a
file: URL is blocked.  (That's a good thing, because otherwise it would be
possible to read someone's prefs file if you knew its location.)  Why aren't src
attributes with chrome: URLs blocked?

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

*** This bug has been marked as a duplicate of 292789 ***

Comment 5

[Jens Bannmann]

Since this was duped against a public bug, please remove the security flag.

Comment 6

[Daniel Veditz [:dveditz]]

(In reply to comment #3)
> <script> must be doing some kind of CheckLoadURI[....] Why aren't src
> attributes with chrome: URLs blocked?

Because Vidur told it not to, apparently
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/base/src/nsScriptLoader.cpp&mark=517-518#510

Easy enough to fix, wonder who we'd break?

Comment 7

[Hixie (not reading bugmail)]

Remote XUL, apparently, see bug 292789.

Comment 8

[Wallace Bagwell]

(In reply to Daniel Veditz [:dveditz] from comment #6)

(In reply to comment #3)

<script> must be doing some kind of CheckLoadURI[....] Why aren't src
attributes with chrome: URLs blocked?
https://bootypics.me/pin/big-juicy-phat-ass-repost-gisellelynette-and-big-ass-picturei-girl/
Because Vidur told it not to, apparently
https://bigasspics.me/pin/michael-kors-brown-booties-repost-misssperu-and-big-butt-korean-women/
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/base/src/
nsScriptLoader.cpp&mark=517-518#510

Easy enough to fix, wonder who we'd break?

tnx