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)

x86
All
defect
Not set
normal

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/
note bug 250725
Summary: Dragging a scrollbar two times allows to execute arbitrary code → Dragging a scrollbar two times allows to execute arbitrary code
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]
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.
> 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.
> 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.
(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...)
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.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned
the name CAN-2005-0527 to this issue.
Whiteboard: [sg:fix] → [sg:fix] exploit blocked by fixing 280664
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
This exploit is fixed.
Group: security
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Flags: testcase+
Flags: in-testsuite+ → in-testsuite?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: