301186 - "Content-disposition: attachment;filename=a.exe" can be used as part of tricking user into running a downloaded executable

Status: RESOLVED WONTFIX

(Firefox :: General, defect)

Description

[Michael Krax]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9) Gecko/20050711 Firefox/1.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9) Gecko/20050711 Firefox/1.0.5

The keyboard shortcut ALT + "click on a link" allows to automaticly save a link
target to your download directory (which is default your desktop). By modifying
header data you can alter the download of the URL
"http://www.example.com/foo.txt" (shown in the status bar when hovering above
the link) into "foo.exe" instead of "foo.txt". Since windows hides known file
extensions by default and an exe file can have any icon, average users probably
don't see the difference an could be tricked into executing a file.

Reproducible: Always

Steps to Reproduce:
1. Open http://bugzilla:[e-mail]/firesaving2/
2. Alt-Click on the demo link




Even with visible file extensions an attacker could try .hta files to trick the
user (.hta = Hyptertext Applications. Associated with Internet Explorer and able
to run arbitrary code.). Most users will assume it's just another variant of the
.htm/.html extension. 

A realistic attack scenario would be some kind of MP3 download website. Users
will probably mass download those files using ALT+click, since using a right
click context menu for each file is annoying and left clicking will probably
play the file in an associated media player/plugin like quicktime. If you mix an
EXE file under the MP3s users will probably don't recognize. 

Another problem is that the MSN toolbar that adds some tabbed browsing to
Internet Explorer uses the ALT + "click on a link" shortcut to open links in a
new tab. When switching between the browsers you easily mix that up and can
accidently download executable files. 

What about adding a whitelist for save to download files (.htm/.html/.txt) and
raise a download dialog for all other filetypes? Maybe add a config switch to
disable and restore the current behavior for "brave power users" that accept the
risk this feature has.

Comment 1

[Michael Krax]

The trunk behaves differently. Maybe this is on purpose or a regression. See bug
#301193. On trunk you can still directly download the pure .exe link though.

Comment 2

[Jesse Ruderman]

See also bug 249951 comment 5.  I'm not marking this as a dup because I'm not
sure exactly what bug 249951 covers.

This is also a problem when surfing porn.  If you download a bunch of video
clips, you're probably not going to look at the extension of every file carefully.

This problem isn't limited to Alt+click, but also applies to Save Link As...,
the dialog that appears when you left-click a link to an .exe file, etc. 

Possible solutions:
(A) Display a warning dialog when downloading an exe.
(B) Wrap downloaded exes with something that displays a warning dialog when you
run them from Explorer.
(C) Put executable downloads in a subdirectory called "Downloaded appliciations"
so users won't run them accidentally.

I prefer (A), because it doesn't require making the UI more complicated in the
case where a user left-clicks a link to an executable.  The new warning dialog
can replace the "What do you want to do with this file?" download in the .exe
case, where users currently don't have a choice except between saving and
cancelling.

Comment 3

[Asa Dotzler [:asa]]

Dan, is this something we need to get for b4?

Comment 4

[Chris Beard]

(In reply to comment #3)
> Dan, is this something we need to get for b4?

adding to the blocking list for b4.  who should we get to take a look at this?

/cb

Comment 5

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

We're going to minus this for 1.8b4, but we'd take a fix (A is preferred) if we
can minimize l10n impact, and will revisit it for a post-1.5 release.

Comment 6

[Jesse Ruderman]

I don't think the "Content-Disposition... filename" trick makes bug 249951 (lack of warning / partitioning when downloading an executable files) much worse.  The Status bar link-target indication can already be "spoofed" in various ways using JavaScript, so this is only an issue if you get download links from a site that has JavaScript disabled (forums, webmail, Thunderbird, or you have JavaScript disabled or use NoScript).  Once bug 249951 is fixed, the "Content-Disposition... filename" trick will be less of a security problem.

Comment 7

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

This is no longer an issue because of the changes in bug 160454 (via bug 294759). That in turned caused bug 299372, which means that the Content-disposition header is now ignored. It's not really clear how we intend to fix bug 299372, but I think it's pretty likely that any patch for bug 299372 would re-introduce this issue.

Comment 8

[Daniel Veditz [:dveditz]]

Could we unhide this bug, mark it "WFM" (or even FIXED since we know what fixed it), and make it block bug 299372? Then we'd have a fighting chance of actually retesting this.

Comment 9

[Michael Krax]

To me it's fine opening up this bug if it helps to either fix it or calling it an expected behavior. A possible solution would be to explain the implicit risk in the documentation of Firefox in a prominent way along with the shortcut feature description and see how bug 299372 develops.

We have "known issues" for usual bugs, why not also start to document known issues of security topics. Everything is better than keeping it another 2 1/2 years under the carpet.

Comment 10

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

(In reply to comment #9)
> To me it's fine opening up this bug if it helps to either fix it or calling it
> an expected behavior.

As mentioned in comment 7, this bug is already fixed, in current trunk builds. We've just kept it open and security-sensitive because we expect it might be unfixed by a patch for bug 299372. Daniel was just asking whether we could make the bug status reflect that state (by un-hiding and resolving) and then just ensuring that the patch for bug 299372 doesn't regress it.

Comment 11

[Reed Loden [:reed]]

So, bug 299372 is fixed now, but the testcase in the URL field is no longer available. Can anybody confirm this is still WFM now that bug 299372 is fixed?

Comment 12

[Jesse Ruderman]

Using http://www.squarefree.com/bug301186/, I can reproduce with the context menu command "Save Link As..." but not with Alt+click.  The testcase consists mostly of a .htaccess file with

<Files *.txt>
ForceType application/octet-stream
Header set Content-Disposition "attachment;filename=a.exe"
</Files>

So, not really WFM.  And I think the Alt+click behavior is a bug.

Comment 13

[Jesse Ruderman]

I think "fixing" the filename-switcheroo part of this attack would end up breaking a lot of legitimate software downloads, while having very little impact on security.  Fixing bug 249951 is the way to go here.