Drag-and-dropped link skips CheckLoadURI

RESOLVED DUPLICATE of bug 285438

Status

()

defect
P1
minor
RESOLVED DUPLICATE of bug 285438
15 years ago
15 years ago

People

(Reporter: jruderman, Assigned: jst)

Tracking

Trunk
x86
Windows XP
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.7.5 +
blocking-aviary1.0PR -
blocking1.8a3 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:fix])

Attachments

(1 attachment, 2 obsolete attachments)

Requirement to exploit: 
 Convince the user to drag something (within the browser window is sufficient).

Impact:
 CheckLoadURI bypassed.  I don't remember how bad this is.
Posted file demo (obsolete) —
Demo CSS based on demo in bug 206859.
Flags: blocking1.8a2?
Posted file demo
The other demo probably only works on Windows.	This one uses a chrome: URL
instead of a file: URL.
Attachment #152746 - Attachment is obsolete: true
If you combine this with bug 250862, this is an arbitrary code execution hole. 
See demo in bug 250862 comment 1.
Dropping a link is considered the same thing as entering it in the URL bar and
is used by folks to load things off their desktop or from an in-browser
directory listing. Maybe the check should be when we start dragging rather than
on the dropping, but we'd have to explain why this was different than copy/paste
into a URL-bar.

I don't see a pressing reason to allow drops of non-document links like
javascript: (are there any others that don't replace the document?), as long as
it doesn't interfere with bookmarklets saved as actual bookmarks.

-> Johnny
Assignee: dveditz → jst
Component: Security: General → DOM: Events
Flags: blocking1.8a3?
Flags: blocking1.7.2?
Flags: blocking-aviary1.0PR?
Btw, this check has to be done for dragged text as well as dragged links.
personally i rely on these drags to work.

i'd rather we fix the status bar and a tooltip to not be forgable or otherwise
obscurable so that people can see what they're actually taking with them.
timeless: stop relying on security holes :)
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR+
Flags: blocking1.8a3?
Flags: blocking1.8a3+
Flags: blocking1.8a2?
Flags: blocking1.7.3?
Flags: blocking1.7.3+
Flags: blocking1.8a3+ → blocking1.8a3-
I tested this a bit, and while it's possible to drop a chrome: URL into the
content area, it doesn't seem to be possible to do the same for a javascript: URL.

Personally I don't see how being able to drop a chrome: URL is all that bad, but
being able to drop a javascript: URL would be, but as that doesn't seem
possible, I don't see this as a serious security exploit.
jst: Did you try the demo in bug 250862?
No, I wrote up my own testcase, and obviously something went wrong there... With
that testcase I do see the bug.

I've got a patch that fixes that for Firefox, attaching...
Whiteboard: [have patch]
Comment on attachment 156548 [details] [diff] [review]
Prevent dropping javascript: and data: URLs into firefox.

Moving this to bug 250725 where it belongs.
Attachment #156548 - Attachment is obsolete: true
Blocks: 250862
minus on this one since it is now tracked in 
http://bugzilla.mozilla.org/show_bug.cgi?id=250862 
Flags: blocking-aviary1.0PR+ → blocking-aviary1.0PR-
Whiteboard: [have patch] → [sg:fix]

*** This bug has been marked as a duplicate of 285438 ***
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Group: security
You need to log in before you can comment on or make changes to this bug.