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 email@example.com
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).
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.
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.
i think it was just something like data:text/html,<a href="pathto.exe">drag this to download button</a>
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
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?
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?
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.
See also bug 510670?