288164 - (firebooking) Bookmarks can access chrome:// and javascript:

Status: RESOLVED INACTIVE

(Firefox :: Bookmarks & History, defect)

Description

[Michael Krax]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.6) Gecko/20050321 Firefox/1.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.6) Gecko/20050321 Firefox/1.0.2

Bookmarks can open URLs including chrome:// and javascript:. This allows to
execute javascript code (e.g. to steal cookies) in the page currently displayed
when opening a bookmark. If you open two bookmarks after another, and the first
is a chrome:// url this allows to run arbitray code.

Reproducible: Always

Steps to Reproduce:




I know this attack vector is mainly a theoretical since it requires a lot of
user interaction, but i start this report anyway to make sure this behavior is
fully intendend. There could also be easier ways of injecting malicious
bookmarks with one of the many "bookmark manager" extensions, bookmark import or
online bookmark sharing (again, just a theorie).

While the javascript: behavior seems to be intended (since this is well known as
"bookmarklets") the chrome:// access seems a little useless and only available
since no check is applied at all. 

What about ristricting the access by default with a whitelist
(http,https,ftp,ftps,javascript,etc) or at least blacklist chrome://. By
blocking chrome:// i see no feature loss for 99% of the user base (tell me if i
am wrong). Bookmarklets are another story. In this case the theoretical security
concerns probably are not worth sacrificing such a powerfull feature (maybe add
a warning dialog when adding a javascript: link?). 

By adding the list to about:config, extension developers could activly re-enable
chrome support since they might have legitimate use of accessing chrome via a
bookmark.

Comment 1

[Michael Krax]

Sorry, forgot proof-of-concept link: http://www.mikx.de/firebooking/

Comment 2

[Mike Connor [:mconnor]]

javascript: is intended, all browsers do this.

As for using bookmark manager extensions to take advantage of this... those are
already chrome, and can do whatever they want within the app already.  No big
deal there.

I could go either way on adding/allowing chrome:// URLs, I don't think its an
exploit as much as just more surface area to potentially exploit.  There might
be something to be said about disallowing bookmarking of URLs from links if the
link can't be accessed directly, but I don't think that represents an inherent
risk, any more than any other interactive prompt does.

Comment 3

[Daniel Veditz [:dveditz]]

javascript bookmarks are not a problem, there's a whole sub-community devoted to
creating and collecting nifty "bookmarklets". For Mozilla examples see
http://www.squarefree.com/bookmarklets/

Running privileged chrome in a browser window is a key stepping stone for a lot
of past exploits and I plan on neutering it in future versions (bug 286651).

Comment 4

[Ben Bucksch (:BenB)]

Michael recommends to leave javascript: as-is and block chrome: by default
(possible to enable with hidden config). I would agree with that, imagine a
"Bookmark this" link (we knew that was possible), and there aren't many valid uses.

Comment 5

[Daniel Veditz [:dveditz]]

Should we clear the confidential flag? This is known, even somewhat desired,
behavior.

Comment 6

[Daniel Veditz [:dveditz]]

*** Bug 290156 has been marked as a duplicate of this bug. ***

Comment 7

[Mike Connor [:mconnor]]

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change

Comment 8

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.