Closed
Bug 426285
Opened 17 years ago
Closed 17 years ago
Image drag-n-drop creating executable files ("firedragging"/ MFSA 2005-25) is back
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: dveditz, Assigned: roc)
References
()
Details
(Keywords: regression, Whiteboard: [sg:moderate])
Attachments
(1 file)
3.68 KB,
patch
|
jst
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
Dragging a hybrid image file can result in a an executable file saved on the user's desktop with an executable extension. The "firedragging" exploit fixed in Firefox 1.0.1 appears to be back on trunk.
http://www.mozilla.org/security/announce/2005/mfsa2005-25.html
Since it may be a new cause, and the bug remains fixed for Firefox 2, it seems best to open a new bug than reopen bug 279945.
PoC at http://www.mikx.de/firedragging/
Reported to security@mozilla.org by Fernando Muñoz (who plans to blog about this -- http://blog.beford.org/)
Flags: wanted1.9.0.x?
Flags: blocking1.9?
Reporter | ||
Updated•17 years ago
|
Whiteboard: [sg:moderate]
Reporter | ||
Comment 1•17 years ago
|
||
regressed between builds 2006-02-20-08 and 2006-02-23-09 -- unfortunately can't narrow down any further because on 2/21-22 builds dragging the image crashes.
I think that makes bug 267426 / bug 328077 the most likely culprits.
Reporter | ||
Updated•17 years ago
|
Summary: Image drag-n-drop creating executable files ("firedragging") is back → Image drag-n-drop creating executable files ("firedragging"/ MFSA 2005-25) is back
Updated•17 years ago
|
Flags: in-litmus?
Assignee | ||
Comment 2•17 years ago
|
||
nsDataObj::GetDownloadDetails doesn't get the file name from the kFilePromiseDestFilename data flavour, that's the problem. I can write a patch to do that, but right now I'm a little confused because nsDataObj comment says
// Get data for flavor
// The format of the data is (URLSTRING\nFILENAME)
for kFilePromiseURLMime, and I'm checking to see if that's true...
Assignee: nobody → roc
Assignee | ||
Comment 3•17 years ago
|
||
No-one ever actually uses the "URL\nFILENAME" format for kFilePromiseURLMime data. That's only used for kURLMime.
So instead of trying to parse that, we should just check for kFilePromiseDestFilename and use that if available. We still need to fall back to the filename part of the URI when kFilePromiseDestFilename is not available. Mailnews and maybe other XUL apps depend on that.
Attachment #312890 -
Flags: superreview?(jst)
Attachment #312890 -
Flags: review?(jst)
Assignee | ||
Updated•17 years ago
|
Whiteboard: [sg:moderate] → [sg:moderate][needs review]
Updated•17 years ago
|
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Comment 4•17 years ago
|
||
Can we get this +'d for blocking 1.9?
Flags: blocking1.9+ → blocking1.9?
Priority: P2 → --
Comment 5•17 years ago
|
||
Shoot.. sorry, i think i midair'd, as the flag was a ? before. Can someone please + again? thanks.
Assignee | ||
Updated•17 years ago
|
Flags: blocking1.9? → blocking1.9+
Updated•17 years ago
|
Attachment #312890 -
Flags: superreview?(jst)
Attachment #312890 -
Flags: superreview+
Attachment #312890 -
Flags: review?(jst)
Attachment #312890 -
Flags: review+
Assignee | ||
Comment 6•17 years ago
|
||
checked in
Status: NEW → RESOLVED
Closed: 17 years ago
Flags: wanted1.9.0.x?
Resolution: --- → FIXED
Whiteboard: [sg:moderate][needs review] → [sg:moderate]
Reporter | ||
Updated•12 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•