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

Status: RESOLVED WORKSFORME

(Firefox :: File Handling, defect)

Description

[Paul Nickerson]

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 [e-mail]

Comment 1

[Jesse Ruderman]

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).

Comment 2

[Jesse Ruderman]

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.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

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.

Comment 4

[Paul Nickerson]

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

Comment 5

[Daniel Veditz [:dveditz]]

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

Comment 6

[Justin Dolske [:Dolske]]

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

[Jesse Ruderman]

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.

Comment 8

[Justin Dolske [:Dolske]]

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

[Jesse Ruderman]

The link in comment 7 is just sending an explicit content-type.

Comment 10

[Matthew N. [:MattN]]

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.

Comment 11

[Justin Dolske [:Dolske]]

See also bug 510670?

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:Gijs, could you have a look please?

For more information, please visit BugBot documentation.

Comment 14

[:Gijs (he/him)]

Neil, could you check if there's anything left to do here after bug 1746052, which should have tackled the myriad outcomes listed in comment #10 (I hope) ?

Comment 15

[Neil Deakin]

Those cases are all fixed. We should open more specific bugs with testcases if there is further work to do.