Closed Bug 250862 Opened 20 years ago Closed 20 years ago

browser accepts dragged javascript: links (same-origin security hole)

Categories

(Core :: DOM: Navigation, defect, P2)

1.0 Branch
x86
Windows XP
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: jruderman, Assigned: jst)

References

Details

(Keywords: fixed-aviary1.0, fixed1.4.4, fixed1.7.3, Whiteboard: [sg:fix])

Attachments

(2 files, 1 obsolete file)

Firefox accepts drags of javascript: links, allowing same-origin violations. Exploiting this hole requires getting the user to cooperate with instructions, but does not require the user to do anything likely to make them suspicious. I think Seamonkey has the same hole. Combined with 250725 (Drag-and-dropped link skips CheckLoadURI), this same-origin hole becomes an arbitrary code execution hole.
Flags: blocking-aviary1.0RC1?
Attached file demo for firefox
This demo works in Firefox and Mozilla, but it works better in Firefox.
Mike, this should block Mozilla 1.7.2.
-> Browser product so we can make it block more releases
Component: General → Embedding: Docshell
Product: Firefox → Browser
Version: unspecified → 1.0 Branch
+ing for dveditz to look at.
Flags: blocking-aviary1.0RC1? → blocking-aviary1.0RC1+
Priority: -- → P5
Why do we allow privileged chrome inside a browser control? A few things (about:config, about:plugins) would have to be moved into a chrome windows of their own if we did that, but might be way safer in the long run. Is javascript: the only scheme that isn't a complete replacement document?
Flags: blocking1.8a3+
Flags: blocking1.7.2+
We should also block data: URLs here, since like javascript: URLs, they inherit their security context from the previous page. (The fact that they can also act as replacement URLs caused both Mozilla and IE to be vulnerable to bug 88167.)
Priority: P5 → P2
dan any updates on when a patche will be ready for this?
Flags: blocking1.8a3+ → blocking1.8a3-
why not disallow dragging into location bar if the protocol or the begining of the URL is not "http" or "https" ? i don't see any functional advantage of dragging into location bar compared to clicking or middle clicking.
sorry, didn't see the demo. obviously the problem is not the location bar.
Attachment #156549 - Attachment is obsolete: true
Comment on attachment 156550 [details] [diff] [review] Same thing for both Firefox and SeaMonkey sr=dveditz
Attachment #156550 - Flags: superreview+
Attachment #156550 - Flags: review?(caillon)
I checked the other onDrops in the codebase (except calendar) and everything else javascript urls are either already rejected or harmless (e.g. setting your home page to a js url).
Assignee: dveditz → jst
Attachment #156550 - Flags: review?(caillon) → review+
Attachment #156550 - Flags: approval1.7.3?
Attachment #156550 - Flags: approval-aviary?
Comment on attachment 156550 [details] [diff] [review] Same thing for both Firefox and SeaMonkey a=asa for branch landings.
Attachment #156550 - Flags: approval1.7.3?
Attachment #156550 - Flags: approval1.7.3+
Attachment #156550 - Flags: approval-aviary?
Attachment #156550 - Flags: approval-aviary+
looks like with the patch dragging "file" and "chrome" urls still may work which may lead to trouble. why not use a safe whitelist?
Whiteboard: [have patch]
Depends on: 250725
We decided against blocking chrome for now, we'll need to investigate the results of blocking that more before flipping the switch. Bug 250725 is for tracking that part, but that, in combination with this, is really bad, thus the fix for this to start with.
Whiteboard: [have patch] → [have patch] ready to land
Fixed on trunk, aviary, and 1.7 branches.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Fixed on the 1.7.2 branch now too.
Keywords: fixed1.7.2
Keywords: fixed1.7.2
Whiteboard: [have patch] ready to land → [sg:fix] fixed1.7.2+
Verified with Firefox 0.10 and Mozilla 1.7.3 on windows XP
Group: security
Whiteboard: [sg:fix] fixed1.7.2+ → [sg:fix] fixed1.7.3
verified windows 1.7.5 12/15
Status: RESOLVED → VERIFIED
Keywords: fixed1.7.5fixed1.7.3
Whiteboard: [sg:fix] fixed1.7.3 → [sg:fix]
What about images in data: URL's? It could be useful to allow these, as right now there's a little incoherence: you can drag file: or http: based images but not data: ones.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: