Open
Bug 1463533
Opened 7 years ago
Updated 1 year ago
When a specially-crafted input text value containing a privileged URL scheme (eg: chrome: URL) of a prompt() dialog is dragged and dropped to the "home" icon, the home page can be changed by this privileged URL
Categories
(Firefox :: Toolbars and Customization, defect, P3)
Tracking
()
NEW
People
(Reporter: jordi.chancel, Unassigned, NeedInfo)
Details
(Keywords: csectype-spoof, reporter-external, sec-low)
Attachments
(2 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180514150347
Steps to reproduce:
When a JavaScript prompt(,); dialog appears, its content is automatically selected.
If a prompt(,); dialog contains a privileged URL page like a:
chrome:// page, resource:/// page, jar: page, file:/// , privileged about: page , (and others...)
and if this privileged URL page is dragged and dropped on the 'home' icon,
The home page can be reset to include this normally-unlinkable page as one of the home page tabs.
(example: chrome://browser/content/browser.xul)
------------------
It is possible to hide the privileged URL or show another URL to trap the user (see the next examples).
Some example to hide the unlinkable page in the prompt dialog:
Example 1: It is possible to show another URL than the privileged URL page in the prompt() dialog with the RTLO Character.
prompt("Drag and drop the the selected text below onto the small 'home' icon (beside the Address Bar) and choose yes","chrome://browser/content/browser.xul + [Several Tab Chars] + http://NewHomePage.firefox.org/بت");
Resulting to show this address http://NewHomePage.firefox.org/ in the prompt(,); dialog instead of chrome:// page.
Example 2: It is possible to hide the privileged URL page with several Tabulation Characters.
prompt("Drag and drop the the selected text below onto the small 'home' icon (beside the Address Bar) and choose yes","[Several Tab Chars] + chrome://browser/content/browser.xul");
Resulting to make invisible the chrome:// page in the prompt(,); dialog.
STR:
1: Go to the testcase , a javascript prompt(); dialog appears
2: Drag and drop the selected text into the prompt dialog to the "home" icon
Actual results:
The home page can be reset to include a privileged URL / normally-unlinkable page as one of the home page tabs.
Expected results:
To fix this vulnerability, Firefox must forbid that privileged URLs like chrome: to be dragged and dropped in the "home" icon from a javascript prompt(); dialog.
Updated•7 years ago
|
Flags: sec-bounty?
Reporter | ||
Updated•7 years ago
|
Summary: When a prompt(); dialog contains a privileged URL (eg: chrome: page) and user drag and drop it on the home icon, the home page can be reset to include this privileged normally-unlinkable page as one of the home page tabs. → When a specially-crafted input text value containing a privileged URL scheme (eg: chrome: URL) of a prompt() dialog is dragged and dropped to the "home" icon, the home page can be changed by this privileged URL
Reporter | ||
Comment 1•7 years ago
|
||
the video demo.
Updated•7 years ago
|
Group: firefox-core-security
Status: UNCONFIRMED → NEW
Component: Untriaged → Tabbed Browser
Ever confirmed: true
Keywords: csectype-spoof,
sec-low
Comment 2•7 years ago
|
||
Not really sure what the bug is here... The way the prompt displays the input? That the home button accepts this when dragging and dropping?
Flags: needinfo?(dveditz)
Comment 3•7 years ago
|
||
This is less a "bug" than a confluence of edge-cases.
1) There's nothing inherently wrong with a chrome:// homepage. Ultimately about:home _is_ a chrome homepage, and there were certainly legacy add-ons that supplied an alternate chrome:// homepage.
2) There is a CSRF-like risk to chrome:// urls (we can't guarantee that arbitrary params are perfectly safe on all our pages and those of unknown extensions past, present, and future) so we don't let web content link to chrome URLs.
3) Because of (1) we let users specify chrome homepages
4) this example shows a way to fool a user to perform (3) to violate (2).
There was a previous bug report where a user was convinced to drag innocuous-looking items from the web page and drop it on the home button to set a chrome homepage. We fixed that by tagging the source of the drag as being the web page. This is similar, but the hidden text comes from one of our own dialogs so I guess it's not tagged with the originating principal the same way.
Choices?
a) We could make sure text selected from alert/confirm/prompt are tagged with the page's principal I guess, and then keep whacking that mole as new sources of untagged-but-web-sourced text are used for similar social-engineering attempts.
b) we could change the selection behavior for prompt() so it can't be easily dragged. Probably going to annoy the people who made it default-selected in the first place, and it's still just whacking moles.
c) don't allow users to set chrome: homepages. We'd have to allow about: pages for our current use, and some about: pages allow params so this is just reducing the scope of privileged pages we'd have to police.
d) don't allow dropping on to the home icon to set anything but https:// urls (yeah, not even http: -- why not?). For anything else users would have to go into prefs and set their homepage.
Option (d) is the approach that stops the whack-a-mole. I'm probably being obnoxious about http: so we can allow that, too, but not file:// or anything else. file:// can be a perfectly reasonable home page, but this could also be an avenue for a web page to get a user to open a specific file:// and there's some risk to that. Doesn't seem unreasonable to ask people to go into about:preferences to set homepages with other schemes since it's pretty edge-casey.
Flags: needinfo?(dveditz)
Comment 4•7 years ago
|
||
d) sounds reasonable to me. Based on this, I'll move this to Toolbars and Customization which seems to fit a bit better than Tabbed Browser.
Component: Tabbed Browser → Toolbars and Customization
Updated•7 years ago
|
Priority: -- → P3
Updated•7 years ago
|
Flags: needinfo?(gijskruitbosch+bugs)
Comment 5•7 years ago
|
||
(In reply to Daniel Veditz [:dveditz] from comment #3)
> d) don't allow dropping on to the home icon to set anything but https://
> urls (yeah, not even http: -- why not?). For anything else users would have
> to go into prefs and set their homepage.
>
> Option (d) is the approach that stops the whack-a-mole. I'm probably being
> obnoxious about http: so we can allow that, too, but not file:// or anything
> else. file:// can be a perfectly reasonable home page, but this could also
> be an avenue for a web page to get a user to open a specific file:// and
> there's some risk to that. Doesn't seem unreasonable to ask people to go
> into about:preferences to set homepages with other schemes since it's pretty
> edge-casey.
I actually think there's 2 bits of whack-a-mole going on here... one is for the source of the drag info which you mentioned, but the other is for the target of the drop. You can also drop on the identity box, tabstrip, url bar, the bookmarks toolbar, the new tab/window buttons, the downloads button, you can use copy + 'paste and go' in the url bar, ... probably more places that I can't think of right now. So not sure how much just fixing the home button helps. :-(
Updated•7 years ago
|
Flags: sec-bounty? → sec-bounty-
Updated•3 years ago
|
Severity: normal → S3
Updated•1 year ago
|
Keywords: reporter-external
You need to log in
before you can comment on or make changes to this bug.
Description
•