Closed
Bug 281807
Opened 19 years ago
Closed 19 years ago
Dragging a scrollbar two times allows to execute arbitrary code
Categories
(Core :: DOM: Copy & Paste and Drag & Drop, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: mikx, Assigned: dveditz)
References
()
Details
(Whiteboard: [sg:fix] exploit blocked by fixing 280664)
Attachments
(1 obsolete file)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050205 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 By combining mutliple vulnerabilities it is possible to hijack the process of using a scrollbar (which is a drag and drop gesture) and silently run arbitray code (UniversalXPConnect). Reproducible: Always Steps to Reproduce: 1. Open http://www.mikx.de/firescrolling/ 2. Use the scrollbar two times Actual Results: The file c:\booom.txt gets created. Expected Results: Disallow the plugin to open a chrome:// url (this is fixed due #280664) Disallow that you can silently open another chrome:// using drag and drop Disallow javascript urls to be opened when dragged to a chrome:// url (this is fixed on tabs due #280056, but not on the "Go" button) Using flash the demo opens chrome://browser/content/browser.xul in an invisible frame. This frame follows the mouse pointer, the "Go" button always stays under the mouse (using the XUL drag event handler). When the users tries to scroll the scrollbar he actually initates a drag and drop event (the scrolling gets emulated via javascript). When he scrolls the first time, another chome url gets dropped onto the Go button the get chrome// privileges inside the window. When he scrolls the second time an javascript: link get dropped and executes with full privileges (UniversalXPConnect). To check it's working the proof-of-concept created the file c:\. Since the bug partly depends on the UI make sure you are using a default Firefox 1.0. This bug is based on #279945, #280056 and #280664, but also contains new components like the Go button drop and passing drag events into a non-xul environment (not sure if this is an expected feature or not). Since you can open any chrome:// url invisible you can for example also make the user change his cookie or SSL settings. Anything you can imagine by "blindly" using any browser component. This bug is somewhat a Firefox port of http://www.mikx.de/scrollbar/
Comment 1•19 years ago
|
||
note bug 250725
Summary: Dragging a scrollbar two times allows to execute arbitrary code → Dragging a scrollbar two times allows to execute arbitrary code
Assignee | ||
Comment 2•19 years ago
|
||
Reassigning to myself so it doesn't look like we're ignoring this. In the near term this is a duplicate of bug 280664 -- once plugins can no longer open privileged chrome urls (now fixed though not yet in a release) this attack no longer works. But *nothing* should ever be able to open a privileged document inside a non-privileged document. We thought that was already the case prior to bug 280664, what if there's another hole? If another bypass is found then this attack is still possible. At the very least I'm leaving this bug open to investigate the possibility of neutering chrome: sub-documents. Possibly we should neuter any chrome: url opened in a browser--even the top-level document--with an exception for explicitly privileged about: URIs. I don't believe dropping javascript: on the Go button or the url bar--in their legitimate chrome location--represents a serious hole. I could be wrong, thoughts? Anything dropped runs in the context of that page. If you've dragged it *from* that page the worst the page can do is hack itself (note: this *is* a problem if another frame injection hole like bug 246448 is found, or given the ability of an attacker to get such link and instructions embedded in the target site such as blog comments or the like. Or Gmail/hotmail/etc?). A spoofer also might be able to convince someone to drag (or copy/paste) from one window onto the urlbar/go button in another window opened on the target site. Users should understand dragging onto the urlbar or go button will take them somewhere else. They surely do not understand the issue with javascript: urls, though one can hope it would be suspicious when the evil site first opens a window but somehow can't manage to open it on the right contents and needs the user to drag something. Or suspicious that the user should do anything but *click* to open a link. The phishers and social engineers are far more clever than I am, maybe we do need to block these everywhere. Hopefully we can do it without breaking legitimate bookmarklets, worst case we could add a hidden developer pref to re-enable them.
Assignee: nobody → dveditz
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [sg:fix]
Assignee | ||
Comment 3•19 years ago
|
||
I'm not sure this is the right approach but I attach it to spark discussion. I tested without the plugin url-loading fix for bug 280664 and this *does* stop both the fireflashing and firescrolling exploits. The about:config in fireflashing is simply powerless, exploit defanged. In firescrolling, however, the chrome URLs can still be loaded into their frames and appear to have full powers. Apparently nsCachedChromeChannel does not have an owner during the load, but sometime later CAPS or someone is granting powers based on the chrome: scheme. Power is removed from the javascript: url that's dropped, saving the day, but I don't like the fact that the chrome URLs got loaded with privileges. I guess backing up, is there ever a legitimate reason to load an empowered chrome: url into a browser content window? Other than the limited number of special about: cases (which are dangerous enough but are explicit "features") there's no reason a user would ever want to do that. Not seeking formal reviews on this patch, I've not tested enough to make sure nothing else broke. But I would like feedback on the approach.
Comment 4•19 years ago
|
||
> is there ever a legitimate reason to load an empowered chrome: url into a
> browser content window?
I can't think of any offhand (though people do it often to get things like
"mailnews in a tab", we don't support that sort of thing at all).
Biesi, I assume error pages don't need to be empowered, right?
Also, if we can figure out a way to reset the principal to what it "should be",
that would be good... Or does setting it null here make us generate a principal
based on URI somewhere else later?
Finally, nsCachedChromeChannel isn't really a necko channel; it just claims to
implement the API (and doesn't); this is probably the root of the problems we're
seeing with it.
Comment 5•19 years ago
|
||
> Nothing should ever be able to open a privileged document inside a > non-privileged document. Why? I tend to agree, but my reasons (transparent iframes, timing attacks) apply just as well for the statement "nothing should be able to open a *more* privileged document inside a *less* privileged document". That would require disabling third-party cookies. > Possibly we should neuter any chrome: url opened in a browser--even the > top-level document--with an exception for explicitly privileged about: URIs. If you have an exception for about:config, what's the point? mikx's exploit for "fireflashing" (bug 280664) used about:config. > I don't believe dropping javascript: on the Go button or the url bar--in their > legitimate chrome location--represents a serious hole. It might be safe if you assume: * It's impossible to switch or close tabs during a drag. * It's impossible to focus or close windows during a drag. * Users won't drag from one window to another. But I'm not comfortable with all of those assumptions.
Comment 6•19 years ago
|
||
(In reply to comment #4) > Biesi, I assume error pages don't need to be empowered, right? correct, they don't. (although I believe they currently are...)
Reporter | ||
Comment 7•19 years ago
|
||
This proof-of-concept is going to be made public after the release of Firefox 1.0.1, which fixes most of it. Just to let you know beforehand.
Reporter | ||
Comment 8•19 years ago
|
||
The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0527 to this issue.
Assignee | ||
Updated•19 years ago
|
Whiteboard: [sg:fix] → [sg:fix] exploit blocked by fixing 280664
Assignee | ||
Comment 9•19 years ago
|
||
Comment on attachment 174203 [details] [diff] [review] nuke system principal on content subframes There's little point in doing this just for sub-frames. We should fix bug 286651 instead.
Attachment #174203 -
Attachment is obsolete: true
Assignee | ||
Comment 10•19 years ago
|
||
This exploit is fixed.
Group: security
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Updated•19 years ago
|
Flags: testcase+
Updated•17 years ago
|
Flags: in-testsuite+ → in-testsuite?
You need to log in
before you can comment on or make changes to this bug.
Description
•