Closed Bug 405926 Opened 12 years ago Closed 12 years ago
** Vulnerable in the past ** Executes in chrome (plugged in 2 and 3) ** TODO: confirm js and data URIs not in places UIs ** http://mxr.mozilla.org/seamonkey/ident?i=PU_checkURLSecurity ** http://mxr.mozilla.org/seamonkey/source/browser/components/places/content/utils.js#1251
Since this is a dependency of bug 375898, marking P2 so it stays on our radar for Fx3 triage/tracking.
Priority: -- → P2
Target Milestone: --- → Firefox 3 beta4
Whiteboard: [sg:investigate] (prevent potential critical/sg:high or sg:critical
Whiteboard: [sg:investigate] (prevent potential critical/sg:high or sg:critical → [sg:investigate] (prevent potential critical/high bugs)
Flags: blocking-firefox3? → blocking-firefox3+
Target Milestone: Firefox 3 beta4 → Firefox 3
Whiteboard: [sg:investigate] (prevent potential critical/high bugs) → [swag: 1d][sg:investigate] (prevent potential critical/high bugs)
Jesse, do you know if there are any automated tests in the tree for privilege escalation like this scenario? Here's what I've tested manually: configurations: - normal - "open in sidebar" is checked scenarios: - open from toolbar - open from sidebar - open from organizer - open from menu - open in new window via context menu - open in new tab via context menu - open via keyword in location bar - open via autocomplete in location bar
Status: NEW → ASSIGNED
Sorry, I don't know anything about automated tests for privilege escalation bugs, or automated tests for Places.
There are two central APIs that Places uses to open bookmark/history URIs. The first is PlacesUIUtils.openNodeIn(): http://mxr.mozilla.org/seamonkey/search?find=%2Fbrowser%2Fcomponents%2Fplaces%2Fcontent%2F&string=++opennodein Which uses these APIs to open URLs from query result nodes: For "open in sidebar": - sidebar.contentWindow.loadWebPanel - http://mxr.mozilla.org/seamonkey/source/browser/base/content/web-panels.js#96 Otherwise, everything is routed through utilityOverlay.js::openUILinkIn() - http://mxr.mozilla.org/seamonkey/source/browser/base/content/utilityOverlay.js#198 When saving: - saveURL() - http://mxr.mozilla.org/seamonkey/source/toolkit/content/contentAreaUtils.js#88 For opening in a new window: - window.openDialog() to browser.xul, pass url For opening in the current window: - window.loadURI(); For opening in a new tab: - tabbrowser.loadOneTab();
The second API is PlacesUIUtils._openTabset(): http://mxr.mozilla.org/seamonkey/search?find=%2Fbrowser%2Fcomponents%2Fplaces%2Fcontent%2F&string=_opentabset For opening in a new window: - window.openDialog() to browser.xul, pass urls joined by "|" Otherwise it uses: - tabbrowser.loadTabs()
I'm pretty satisfied with the analysis here. We really want a way of ensuring this doesn't change in the future, but that's not a problem I'm going to block the release on.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Verified with rc2 on Win XP all the scenarios in comment #4. I added a test case to litmus to cover the same scenarios.
Status: RESOLVED → VERIFIED
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.