Dragging image to "download" toolbar button allows creating executable files

NEW
Unassigned

Status

()

Firefox
File Handling
--
critical
12 years ago
5 years ago

People

(Reporter: Paul Nickerson, Unassigned)

Tracking

({sec-low})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:low P5], URL)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

Firefox prevents users from dragging well-formed images with non-standard extensions to the local system. However, this behavior does not apply to the action of dragging a well-formed image to the download action icon that is optionally displayed in the toolbar. Malicious data can be appended to the image and any extension can be specified. Dragging the image will result in instant download without prompt.

Reproducible: Always

Steps to Reproduce:
http://www.greyhatsecurity.org/mozilla/dragtodownload.htm
Follow directions

Actual Results:  
vuln.hta is downloaded to the specified download directory

Expected Results:  
either the download prompt should display as if the file was navigated to, or the same path should be followed as when an image is dragged directly to the desktop

Btw, this is a new account. I am the same person as heatsync@gmail.com

Comment 1

12 years ago
Confirmed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051025 Firefox/1.5.

This is as bad as bug 279945, but only for users who take advantage of the drag-to-download-button feature (which I didn't know about until I read this bug).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Inconsistent insecure download behavior → Dragging image to "download" toolbar button allows creating executable files
Whiteboard: [sg:fix]

Comment 2

12 years ago
This will be less of a security problem once bug 249951 is fixed, but it will still be a bug.  It might be a while before bug 249951 is fixed.
Whiteboard: [sg:fix] → [sg:low]
Paul: is the testcase still available somewhere? The given URL doesn't seem to work anymore. Attaching a testcase to the bug would be ideal.
(Reporter)

Comment 4

11 years ago
i think it was just something like data:text/html,<a href="pathto.exe">drag this to download button</a>
(Assignee)

Updated

10 years ago
Product: Firefox → Toolkit
I doubt this would be in the download manager: it's the download button drop target that knows whether it got a link or an image drop and then just passes it off to the downloader. Moving this to a Firefox component
Group: core-security
Component: Download Manager → Toolbars
Product: Toolkit → Firefox
QA Contact: download.manager → toolbars
Whiteboard: [sg:low] → [sg:low P5]
So how is this meaningfully different than the user clicking the link and being presented with a download dialog? (Or right click, Save As)

Or is it just that <a href="foo"><img src="bar"</a> prefers to download foo over bar when doing dnd?

Comment 7

6 years ago
If I drag http://www.squarefree.com/bug314359/google.exe to my desktop, I get a "google.png". If I drag it to the Downloads button on my toolbar instead, I get a "google.exe".

I expect dragging an image to be a safe action, not one that needs to be followed by checking the file's extension.
Ah, that makes sense. Is your test link in comment 7 doing anything more funky than sending an explicit content-type for the request?

A couple of potential fixes:

1) Kill this feature. :-) Alas, with the new download manager (bug 564934) it'll be more common to see a download toolbar button, and even seems more sensible to allow DnD to it (as it feels more containerlike to me, at least from screenshots).

2) Figure out why DnD is taking some different code path and fix that. I sorta suspect something is losing the content type, and something else ends up just assuming no type is needed. Hmm, I wonder if Save Link As does this correctly?

Comment 9

6 years ago
The link in comment 7 is just sending an explicit content-type.
There are as least three different major code paths for the six methods I've found to save an image:

METHOD                  Fx MAC    Fx LINUX Fx WIN  Chrome 14 Dev  IE10 Preview
File > Save Page As…    .exe.png .exe.png .exe.png .exe           .htm with .png
Save Image As…          .exe.png .exe.png .exe.png .exe           .png
Drag image to desktop   .png     .exe     .png     .png           .png (with warning)
Drag image to button    .exe     .exe     .exe     N/A            N/A
Drag <a> to button      .exe     .exe     .exe     N/A            N/A
Page Info -> Media      .exe     .exe     .exe     N/A            N/A

This results in three different extensions (.exe.png, .png, .exe) for Firefox Nightly on Mac OS X as shown in column 1 above.

1) File > Save Page As…  => saveDocument => internalSave
2) Save Image As… calls saveMedia => saveImageURL => internalSave
3) Dragging the image to the desktop is widget OS-specific code ie. nsClipboard::PasteboardDictFromTransferable
4) Other drag/drop stuff uses contentAreaDropListener.js => nsDOMDataTransfer

This problem is not isolated to dragging to the download button or to images but we do already have code (saveImageURL) to handle the image case by looking up the content type in the image cache. This won't help with dragging a link to an image though, as that resource is not downloaded to get the content type until after the save process starts.
OS: Windows XP → All
Hardware: x86 → All
See also bug 510670?
Keywords: sec-low

Updated

5 years ago
Component: Toolbars → File Handling
You need to log in before you can comment on or make changes to this bug.