Created attachment 163051 [details] Testcase - an rss feed I put one up at http://members.rogers.com/mromarkhan/RssFeed.html So you can click the lil RSS icon at the bottom right
Created attachment 163063 [details] [diff] [review] 265668-js-urls-in-livemark-feeds-1.patch 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.
Created attachment 163088 [details] [diff] [review] 265668-priv-urls-in-bmgr-2.patch 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!
(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