250938 - Can open EXE files directly from Firefox if MIME type is application/x-msdos-program

Status: RESOLVED FIXED

(Toolkit :: Downloads API, defect)

Description

[bugzilla]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7) Gecko/20040707 Firefox/0.9.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7) Gecko/20040707 Firefox/0.9.2

Although it should not be possible to select the "open with [dropdownbox]"
option when downloading an .EXE file, you are sometimes able to choose it. I
consider this as unsecure and therefore nominate this bug as a blocker for
Aviary 1.0. It is probably reproduceable under every version of Windows and is
not limited to WinXP only.

I believe this problem occurs when the name of the .EXE file contains spaces,
but I am not quite sure.

Reproducible: Sometimes
Steps to Reproduce:
1. select any file ending in .EXE for download
2. notice the popup box to allow you to select "open with".
Actual Results:  
the download started and the program file opened immediately after it was
finished without further notice.

Expected Results:  
the option "open with" should have been blocked, as it is intended.

Comment 1

[bugzilla]

Attachment: Screenshot, taken with the German version of Firefox 0.9.2

Comment 2

[Ali Ebrahim]

It appears that the MIME type application/x-msdos-program does not trigger the
'safe handling of exe files' mode. We need to fix that.

Comment 3

[Ali Ebrahim]

For me the severity of the bug is somewhat lessened because although I'm allowed
to select Open with exefile, it doesn't actually work. At the end of the
download instead of exectuing the file, it pops up an error saying that the file
could not be opened, because an unknown error occured.

However, we can't be sure this will happen for all files, clearly the reporter's
testcase file did exectute for him. So we still need to fix the bug and add
application/x-msdos-program to the list of MIME types treated as executable files.

Comment 4

[Ali Ebrahim]

For those who are wondering,
http://www.ebrahim.org/mozilla/firefox/bugs/250938/foo.exe is a file that
contains the characters "bar" in them. Nothing more. It doesn't actually do
anything.

Comment 5

[Ali Ebrahim]

Attachment: foo.exe -- application/octet-stream

Comment 6

[Ali Ebrahim]

Attachment: foo.exe -- application/x-msdos-program

Comment 7

[Ali Ebrahim]

Attachment: foo.exe -- application/x-msdownload

Comment 8

[Ali Ebrahim]

I've created the attachments of the three cases where we should be detecting EXE
files. Currently we handle application/octet-stream and application/x-msdownload
correctly, only application/x-msdos-program isn't detected.

I've added attachments to this bug for easy testing.

If anyone knows of any more cases where we should be blocking direct execution
from Firefox, please list the MIME types here for evaluation.

Comment 9

[Ali Ebrahim]

Attachment: Add application/x-msdos-program to list of files not to open

This patch creates a local function isWin32MIMETypeExecutable(mimeType) in each
file where the MIME types of stuff that we shouldn't allow the user to open
from Firefox. This makes the code more readable (and hopefully easier to
maintain).

It also fixes a mistake in
/mozilla/toolkit/mozapps/downloads/content/editAction.js where one of the
blocked MIME types is application/object-stream, which doesn't exist. It
corrects and changes it to application/octet-stream.

Comment 10

[Ben Goodger (use ben at mozilla dot org for email)]

Halt. I have a variant coming that is a little more complete. 

Comment 11

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: use nsIFile's sturdier list, and add handling for the case where a default handler does not exist

This may be technically incorrect since it assumes all files with .exe (etc)
names no matter what the content type are executables but who misnames files
like this anyway...

Also, removes the menulist when there's no default handler and substitutes a
"Browse..." button. The menulist reappears when a handler is selected.

Comment 12

[WD]

I believe this bug is also present in Mozilla:   bug 236967

Comment 13

[Ben Goodger (use ben at mozilla dot org for email)]

I checked this fix in, branch and trunk.