Open Bug 249951 Opened 20 years ago Updated 2 years ago

Safer handling of executable files with download manager

Categories

(Toolkit :: Downloads API, defect)

defect

Tracking

()

People

(Reporter: bugs, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: sec-want, Whiteboard: [sg:want P2])

Attachments

(1 file, 1 obsolete file)

1) Fix all edge cases that allow autodownload of bad types. 2) Replace current dialog (which can be disabled) with: +-------------------------------------------+ | | | You are about to run this program: | | | | @ winword.exe | | | | Description: Microsoft Word for Windows | | Publisher: Microsoft Corporation | | | | Downloaded from: hostname.com | | | | Executable files such as this can contain | | viruses or malicious code that may harm | | your computer. | | | | *You should only run programs from sources| | you trust.* | | | | | | ( Run this Program ) ( Cancel ) | | | +-------------------------------------------+ *text* = bolded @ = icon Notes: - user can no longer disable this dialog. I've been running a firefox build for several months that features this dialog when I (rarely) launch executables and the extra screen is no huge deal. - placing the metadata including the host the file was downloaded from is probably a good idea. Implementation Notes: - more robust checking for executable types in UCT handling code to shut down the ability to create automatic handlers for executable files - add a new XUL dialog to replace the confirmCheck use in download.js - add a method to nsIWindowsShellService to get full description/publisher metadata from a file (maybe this should go on a new nsILocalFileWin??? - i.e. getVersionInformation("Description"), getVersionInformation("InternalName"), etc. ) - where the parameters map to keys in the VERSION string table of the file's resources - add ifdef XP_WIN code to the new XUL dialog that fills that information in.
Status: NEW → ASSIGNED
Flags: blocking-aviary1.0RC1+
Priority: -- → P3
Target Milestone: --- → Firefox1.0beta
"You should run programs only from..." (text correction from brendan)
"Run this Program" should be replaced by "Save this Program" when the dialog is triggered by an action like "Save Link As...". The dialog should have the same protections as the extension installation dialog: * The default button should be "Cancel". * The "Run" and "Save" buttons should be disabled for a short time.
Not to start a holy war, but I'd rather we default to nothing, going along with GNOME HIG (and to a lesser extent, Apple HIG). Defaulting to cancel makes it too easy to accidentally dismiss a dialog, which can be annoying.
Sorry Jesse - I forgot to add this is after the application has been saved already, and the user clicked the "Open" link in the dlmgr. Tweaks to the unknown content type dialog for when file.isExecutable() evaluates to true. +--------------------------------------------+ | | | You have chosen to download | | | | @ FirefoxSetup-0.9.1.exe | | | | from: ftp.mozilla.org | | | | Executable files such as this can contain | | viruses or malicious code that may harm | | your computer. | | | | *You should only run programs from sources | | you trust* | | | | | | ( Download this Program ) (( Cancel )) | | | +--------------------------------------------+ Also - IE SP2 uses a permission manager to control all file downloads. Is that worth doing? (Separate bug definitely)
That dialog will also appear if I right-click a link to an executable and select "Save Link As..." or Alt+click a link to an executable, right?
it could be...
I think it should, since I save lots of videos that way and only check the extensions 60% of the time before double-clicking on them in Explorer.
Depends on: 250938
great idea that would help get attention
Attached patch some doodling (obsolete) (deleted) — Splinter Review
a rough cut at some of this - far from the final approach. this doesn't quite work - for some reason when you click on file links they never download. save link as... downloads work though.
Attached patch more doodling (deleted) — Splinter Review
not for review, just for storage
Attachment #153571 - Attachment is obsolete: true
Missing the boat. The changes I made here caused downloads to not work. There are simpler patches in 252189 and 250938 to do some of what's been done here.
Flags: blocking-aviary1.0RC1+ → blocking-aviary1.0RC1-
this dialog would be quite welcome... one of my nits after switching from MSIE to firefox is the extra effort i have to put into running executables, the dialog really needs a "run this program" option for advanced users. -dean
*** Bug 272222 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1? → blocking-aviary1.1-
Depends on: 301186
See also bug 301186.
Adding a warning when downloading executable files, or marking/segregating downloaded executable files in some way, would help users who: (1) don't know enough about file extensions to keep themselves safe when downloading porn videos. (2) don't even think of the possibility that the file they downloaded isn't a video, and so neglect to look at the extension. (3) download so many porn videos that they sometimes forget to check the file extension for some of them.
Whiteboard: [sg:want P2]
Assignee: bugs → nobody
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: ali → download.manager
Target Milestone: Firefox1.0beta → ---
This seems like it would be related to bug 236771.
Great proposal. Was surprised to see that. Just one thing: From the initial description, it seems you want to get the Description and Publisher from the metadata in the EXE itself. Of course that's flawed. If you show "Microsoft", it should be certified, otherwise show the hostname only.
I've heard that if you download an application using Firefox trunk on Leopard or XP SP2, and then double-click on it in Finder or Explorer, the OS will warn you that you're about to run a downloaded application. So I guess we don't need to warn on Alt+click executable downloads after all :) The existence of these OS dialogs could make it safer to include a "Launch" button in our own dialogs, as well.
Product: Firefox → Toolkit
> See also bug 301186. I get "You are not authorized to access bug #301186." An unpatched security vulnerability has been around since 2005?
(In reply to comment #19) > > See also bug 301186. > > I get "You are not authorized to access bug #301186." An unpatched security > vulnerability has been around since 2005? Looks like someone failed to open it up. Dan? /be
I made it public, and wontfixed it.
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk
Depends on: downloadprotection
How about creating a subfolder called "Downloaded Apps" when we download an executable?
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 14 votes.
:mak, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(mak)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(mak)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: