Closed Bug 426285 Opened 15 years ago Closed 15 years ago

Image drag-n-drop creating executable files ("firedragging"/ MFSA 2005-25) is back

Categories

(Core :: Layout, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: dveditz, Assigned: roc)

References

()

Details

(Keywords: regression, Whiteboard: [sg:moderate])

Attachments

(1 file)

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?
Whiteboard: [sg:moderate]
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.
Blocks: 267426, 328077
Summary: Image drag-n-drop creating executable files ("firedragging") is back → Image drag-n-drop creating executable files ("firedragging"/ MFSA 2005-25) is back
Flags: in-litmus?
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
Attached patch fixSplinter Review
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)
Whiteboard: [sg:moderate] → [sg:moderate][needs review]
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Can we get this +'d for blocking 1.9?
Flags: blocking1.9+ → blocking1.9?
Priority: P2 → --
Shoot.. sorry, i think i midair'd, as the flag was a ? before.  Can someone please + again?  thanks.
Flags: blocking1.9? → blocking1.9+
Attachment #312890 - Flags: superreview?(jst)
Attachment #312890 - Flags: superreview+
Attachment #312890 - Flags: review?(jst)
Attachment #312890 - Flags: review+
checked in
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: wanted1.9.0.x?
Resolution: --- → FIXED
Whiteboard: [sg:moderate][needs review] → [sg:moderate]
Group: core-security
You need to log in before you can comment on or make changes to this bug.