User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 This requires that the current url is chrome. Say for example chrome://browser/content/bookmarks/bookmarksManager.xul. And the user clicks the bookmarklet in this context. <a href="javascript: var m_prefs = Components.classes[&quot;@mozilla.org/preferences-service;1&quot;].getService(Components.interfaces.nsIPrefBranch); m_prefs.setCharPref(&quot;browser.startup.homepage&quot;,&quot;http://visuallinkindicator.mozdev.org/&quot;);">Link</a> - change home page Can be a problem with livemarks. Reproducible: Always Steps to Reproduce: 1. Bookmark link 2. Enter chrome://browser/content/bookmarks/bookmarksManager.xul 3. Click bookmark link Actual Results: Home page changed or javascript with chrome privilege executed. Expected Results: Eventhough it is a nice feature, I think it should deny.

I put one up at http://members.rogers.com/mromarkhan/RssFeed.html So you can click the lil RSS icon at the bottom right

Skip javascript and chrome URLs in live bookmark feeds; note that this makes the test feed show up as "live bookmark failed to load", which is what happens when there are no valid items to load. (Should say Empty, but too late for that.)

Changes based on jst's feedback. Use nsIScriptSecurityManager's CheckLoadURI method for this instead of doing our own homegrown version. (We need to add deps on caps, xpconnect, and js for this though, even to call it from C++..)

Comment on attachment 163063 [details] [diff] [review] 265668-js-urls-in-livemark-feeds-1.patch r+sr=jst

Fixed; thanks for catching this, Omar!

Comment on attachment 163063 [details] [diff] [review] 265668-js-urls-in-livemark-feeds-1.patch a=asa for aviary checkin.

So, you are handling this only for live feeds? If so, this bug still exists, if the user bookmarks a malice URL manually (either by "bookmark this link" or maybe trickily putting a Javascript URL in urlbar and still having an interesting page showing up.

Yeah, ok, Ben's right.. this can be pretty bad. This is a gross hack; however, every bookmarks open funnels in to here, so it's hard to decide where we're actually at. Any alternative suggestions welcome.

This is one of the oldest chrome-privilege-giveaway bugs we had in Seamonkey, we've got to stop making the same mistakes all over again!

Comment on attachment 163088 [details] [diff] [review] 265668-priv-urls-in-bmgr-2.patch >+ // don't allow loading javascript/data urls Add /chrome there... r+sr=jst

(In reply to comment #8) > Created an attachment (id=163088) > 265668-priv-urls-in-bmgr-2.patch wouldn't calling CheckLoadURI here require slightly less hardcoding of various stuff?

(In reply to comment #9) > This is one of the oldest chrome-privilege-giveaway bugs we had in Seamonkey, > we've got to stop making the same mistakes all over again! So, we actually don't have the bug that I thought we did (and that I was trying to fix). I misunderstood the original bug report to mean that bookmarklets executed from the bookmarks manager were running with chrome privs; but that isn't the case. Stripping js/etc. from live bookmark feeds is still valid, so that'll stay; however, the example chrome URL threw me off. The issue here is that if the user navigates to a chrome: URI in a browser window and then runs a bad bookmarklet, that bookmarklet executes with chrome privs. This I'm inclined to say is not a bug then, as it requires: 1) the user manually navigates to a chrome: URI 2) the user executes a bookmarklet that does bad stuff Returning this back to fixed; ignore the second patch.

What protocols are allowed / disallowed in Live Bookmarks with the patch that was checked in?

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

Security Advisories published, clearing confidential flag

See also bug 312108.

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