Last Comment Bug 273498 - (SA13258) [SA13258 no rating] "Save Link As" Download Dialog Spoofing Vulnerability
(SA13258)
: [SA13258 no rating] "Save Link As" Download Dialog Spoofing Vulnerability
Status: VERIFIED FIXED
[sg:fix]
: fixed-aviary1.0, fixed-aviary1.0.1, fixed1.7.5
Product: Core Graveyard
Classification: Graveyard
Component: File Handling (show other bugs)
: Trunk
: x86 Windows XP
: -- major (vote)
: ---
Assigned To: Boris Zbarsky [:bz] (TPAC)
: Hixie (not reading bugmail)
Mentors:
http://secunia.com/advisories/13258
Depends on:
Blocks: 248511 sg-ff101
  Show dependency treegraph
 
Reported: 2004-12-07 01:26 PST by Daniel Veditz [:dveditz]
Modified: 2016-06-22 12:16 PDT (History)
14 users (show)
chofmann: blocking‑aviary1.0.1+
bob: in‑testsuite?
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
proof of concept (707 bytes, application/octet-stream)
2004-12-07 01:27 PST, Daniel Veditz [:dveditz]
no flags Details
Firefox patch (trunk and branch both) (1.25 KB, patch)
2004-12-07 14:59 PST, Boris Zbarsky [:bz] (TPAC)
mconnor: review+
bugs: approval‑aviary+
Details | Diff | Splinter Review
Patch for 1.7 branch (2.39 KB, patch)
2004-12-07 15:03 PST, Boris Zbarsky [:bz] (TPAC)
cbiesinger: review+
neil: superreview+
mozilla: approval1.7.5+
Details | Diff | Splinter Review

Description Daniel Veditz [:dveditz] 2004-12-07 01:26:31 PST
Somewhat similar to bug 267122 and 267123 (SA12979). This one involves
presenting a windows "Save As" dialog that shows one filetype (JPEG, for
example) but actually tacks on a different extension when saved (for example,
.bat). Uses the Content-Disposition header to accomplish this.

Advisory URL is currently a blank placeholder but will help with dupes when the
vulnerability is announced.

- - - -From Secunia- - - - 
Andreas Sandblad, Secunia Research has discovered a vulnerability in Mozilla and
Mozilla Firefox, which can be exploited by malicious people to trick users into
downloading malicious files.

The problem is that Mozilla uses the URL to determine the file type association
in the "Save Link As" download dialog, but uses the filename from the
"Content-Disposition" HTTP header when saving the downloaded file. This can be
exploited by a malicious website to spoof file types in the "Save Link As"
download dialog.

Successful exploitation can lead to malware being saved to the download
directory (default is the desktop on Mozilla Firefox).

NOTE: Exploitation requires that the option "Hide extension for known file
types" is enabled in Windows (default setting).

PoC (Proof of Concept):
SA13258.zip/SA13258/poc.html
(Requires Apache 2 with PHP and "rewrite" module support. ".htaccess" file included)

The vulnerability has been confirmed in Mozilla 1.7.3 and Mozilla Firefox 1.0
for Windows. Other versions may also be affected.
Comment 1 Daniel Veditz [:dveditz] 2004-12-07 01:27:50 PST
Created attachment 168115 [details]
proof of concept
Comment 2 Darin Fisher 2004-12-07 08:40:53 PST
I was able to confirm this problem using Firefox 1.0 on WinXP.
Comment 3 Boris Zbarsky [:bz] (TPAC) 2004-12-07 09:25:13 PST
> The problem is that Mozilla uses the URL to determine the file type association
> in the "Save Link As" download dialog

Note that this is not an issue on SeaMonkey trunk, since we no longer use the
Content-Disposition filename there.

Given that Firefox has forked all this code, this isn't really a core file
handling bug -- it's a bug in the UI code.
Comment 4 Darin Fisher 2004-12-07 09:31:07 PST
boris: it is still a bug in seamonkey 1.7.x, and so the fix might need to be
incorporated into a 1.7.6 release.
Comment 5 Boris Zbarsky [:bz] (TPAC) 2004-12-07 12:53:08 PST
The fix that landed on trunk is really not acceptable for branches... Lemme see
what I can do for branch.
Comment 6 Boris Zbarsky [:bz] (TPAC) 2004-12-07 14:10:48 PST
So I'm betting this is an issue with our interaction with the Windows system
filepicker.  That will automatically modify the filename the user selects, if I
recall correctly, by appending an extension it somehow comes up with (based on
filters or the default filename we gave it up front or something).

I don't recall the exact behavior, and I don't have a way to test it here. I do
recall that the MSDN documentation for the functionality was incorrect, per
testing some people did for me...

If someone can tell me the exact steps they take to reproduce and what the
actual HTTP headers and URI involved are, I may be able to sort out what's
happening by code inspection.
Comment 7 Hixie (not reading bugmail) 2004-12-07 14:51:43 PST
Is there a bug for tracking this issue in the Firefox code?
Comment 8 Boris Zbarsky [:bz] (TPAC) 2004-12-07 14:55:56 PST
I was wrong (largely because I misunderstood which problem was being reported).
 This isn't a filepicker issue per se, just a bug in our front-end code... 
Patches coming up.
Comment 9 Boris Zbarsky [:bz] (TPAC) 2004-12-07 14:59:31 PST
Created attachment 168164 [details] [diff] [review]
Firefox patch (trunk and branch both)
Comment 10 Boris Zbarsky [:bz] (TPAC) 2004-12-07 15:03:07 PST
Created attachment 168166 [details] [diff] [review]
Patch for 1.7 branch
Comment 11 Boris Zbarsky [:bz] (TPAC) 2004-12-07 15:05:35 PST
Comment on attachment 168166 [details] [diff] [review]
Patch for 1.7 branch

The basic idea is to use the defaultExtension, which is our
vetted-against-the-type-and such extension, which takes into account the
Content-Disposition header, when calling appendFiltersForContentType.  The old
code uses the URL extension there, which is wrong.
Comment 12 Boris Zbarsky [:bz] (TPAC) 2004-12-07 15:06:16 PST
Comment on attachment 168164 [details] [diff] [review]
Firefox patch (trunk and branch both) 

Ben, see comment 11 for the explanation of what this patch does.
Comment 13 Boris Zbarsky [:bz] (TPAC) 2004-12-07 15:09:57 PST
Comment on attachment 168164 [details] [diff] [review]
Firefox patch (trunk and branch both) 

Mike, if you get to this before Ben does, is your r= enough to land this on
branch?
Comment 14 Christian :Biesinger (don't email me, ping me on IRC) 2004-12-07 15:24:55 PST
Comment on attachment 168166 [details] [diff] [review]
Patch for 1.7 branch

hmm... trunk needs nothing like this? this would explain some bugs about wrong
extensions though, I think.
Comment 15 Boris Zbarsky [:bz] (TPAC) 2004-12-07 15:46:42 PST
Comment on attachment 168166 [details] [diff] [review]
Patch for 1.7 branch

Requesting branch approval for this security fix.  Note that this is not core
code, so it's fine for 1.7.5.
Comment 16 Mike Connor [:mconnor] 2004-12-09 02:46:34 PST
Comment on attachment 168164 [details] [diff] [review]
Firefox patch (trunk and branch both) 

r=me for trunk and branch.
Comment 17 Boris Zbarsky [:bz] (TPAC) 2004-12-09 07:28:41 PST
Comment on attachment 168164 [details] [diff] [review]
Firefox patch (trunk and branch both) 

Requesting aviary approval for this security fix...
Comment 18 Boris Zbarsky [:bz] (TPAC) 2004-12-09 07:39:43 PST
Comment on attachment 168164 [details] [diff] [review]
Firefox patch (trunk and branch both) 

Checked in on trunk
Comment 19 Mike Kaply [:mkaply] 2004-12-09 13:02:01 PST
Comment on attachment 168166 [details] [diff] [review]
Patch for 1.7 branch

a=mkaply for 1.7.5
Comment 20 Boris Zbarsky [:bz] (TPAC) 2004-12-10 07:15:49 PST
Marking fixed, in fact, since this is now fixed on trunk.
Comment 21 Ben Goodger (use ben at mozilla dot org for email) 2004-12-10 14:54:23 PST
Comment on attachment 168164 [details] [diff] [review]
Firefox patch (trunk and branch both) 

a=ben@mozilla.org
Comment 22 Boris Zbarsky [:bz] (TPAC) 2004-12-10 21:10:58 PST
fixed-aviary1.0, though it's not fixed in 1.0, of course....
Comment 23 Asa Dotzler [:asa] 2004-12-18 11:57:15 PST
1.7.5 has shipped. Moving request to 1.7.6.
Comment 24 Mike Connor [:mconnor] 2004-12-18 12:20:28 PST
its _in_ 1.7.5 based on keywords, so removing blocking flag.
Comment 25 chris hofmann 2005-02-01 15:27:54 PST
need to make sure this gets on the right branch
Comment 26 Daniel Veditz [:dveditz] 2005-02-08 14:51:16 PST
landed on aviary1.0.1 branch
Comment 27 Jay Patel [:jay] 2005-02-17 18:44:28 PST
Verified Fixed.  The php test case shows the proper .bat file in the open file
dialog and saves it with the correct extension.

Aviary 1.0.1 branch: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20050217 Firefox/1.0

Mozilla 1.7.6 branch: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050217
Comment 28 Lloyd D Budd 2005-04-11 19:46:29 PDT
Does anyone have a page up with the test case ?
Comment 29 Bob Clary [:bc:] 2005-07-18 05:13:12 PDT
this is not fixed on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4)
Gecko/20050715 Firefox/1.0+, it still tries to save poc.jpg. It is fixed on
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716
Firefox/1.0.6 where it tries to save my picture.bat.
Comment 30 Boris Zbarsky [:bz] (TPAC) 2005-07-18 08:28:55 PDT
> it still tries to save poc.jpg.

Doesn't it also save "poc.jpg"?  The problem with this bug was that we offered
to save "poc.jpg" but saved "picture.bat"...  Now we're consistent.
Comment 31 Bob Clary [:bc:] 2005-07-18 12:11:59 PDT
(In reply to comment #30)
> > it still tries to save poc.jpg.
> 
> Doesn't it also save "poc.jpg"?  The problem with this bug was that we offered
> to save "poc.jpg" but saved "picture.bat"...  Now we're consistent.

trunk saves "poc.jpg" while 1.0.6 saves "my picture.bat" both containing the
text "call winmine.exe"
Comment 32 Boris Zbarsky [:bz] (TPAC) 2005-07-18 12:25:37 PDT
Right.  That would be expected behavior -- on branch we use the
Content-Disposition header for both filenames, while on trunk we use it for neither.

Note You need to log in before you can comment on or make changes to this bug.