Closed
Bug 273498
(SA13258)
Opened 19 years ago
Closed 19 years ago
[SA13258 no rating] "Save Link As" Download Dialog Spoofing Vulnerability
Categories
(Core Graveyard :: File Handling, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: dveditz, Assigned: bzbarsky)
References
()
Details
(Keywords: fixed-aviary1.0, fixed-aviary1.0.1, fixed1.7.5, Whiteboard: [sg:fix])
Attachments
(3 files)
707 bytes,
application/octet-stream
|
Details | |
1.25 KB,
patch
|
mconnor
:
review+
bugs
:
approval-aviary+
|
Details | Diff | Splinter Review |
2.39 KB,
patch
|
Biesinger
:
review+
neil
:
superreview+
mkaply
:
approval1.7.5+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•19 years ago
|
||
Comment 2•19 years ago
|
||
I was able to confirm this problem using Firefox 1.0 on WinXP.
![]() |
Assignee | |
Comment 3•19 years ago
|
||
> 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•19 years ago
|
||
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.
![]() |
Assignee | |
Comment 5•19 years ago
|
||
The fix that landed on trunk is really not acceptable for branches... Lemme see what I can do for branch.
![]() |
Assignee | |
Comment 6•19 years ago
|
||
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•19 years ago
|
||
Is there a bug for tracking this issue in the Firefox code?
![]() |
Assignee | |
Comment 8•19 years ago
|
||
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.
![]() |
Assignee | |
Comment 9•19 years ago
|
||
![]() |
Assignee | |
Comment 10•19 years ago
|
||
![]() |
Assignee | |
Comment 11•19 years ago
|
||
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.
Attachment #168166 -
Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #168166 -
Flags: review?(cbiesinger)
![]() |
Assignee | |
Comment 12•19 years ago
|
||
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.
Attachment #168164 -
Flags: review?(bugs)
![]() |
Assignee | |
Comment 13•19 years ago
|
||
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?
Attachment #168164 -
Flags: superreview?(bugs)
Attachment #168164 -
Flags: review?(mconnor)
Attachment #168164 -
Flags: review?(bugs)
Comment 14•19 years ago
|
||
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.
Attachment #168166 -
Flags: review?(cbiesinger) → review+
Updated•19 years ago
|
Attachment #168166 -
Flags: superreview?(neil.parkwaycc.co.uk) → superreview+
![]() |
Assignee | |
Comment 15•19 years ago
|
||
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.
Attachment #168166 -
Flags: approval1.7.5?
Comment 16•19 years ago
|
||
Comment on attachment 168164 [details] [diff] [review] Firefox patch (trunk and branch both) r=me for trunk and branch.
Attachment #168164 -
Flags: superreview?(bugs)
Attachment #168164 -
Flags: review?(mconnor)
Attachment #168164 -
Flags: review+
![]() |
Assignee | |
Comment 17•19 years ago
|
||
Comment on attachment 168164 [details] [diff] [review] Firefox patch (trunk and branch both) Requesting aviary approval for this security fix...
Attachment #168164 -
Flags: approval-aviary?
![]() |
Assignee | |
Updated•19 years ago
|
Assignee: file-handling → bzbarsky
![]() |
Assignee | |
Comment 18•19 years ago
|
||
Comment on attachment 168164 [details] [diff] [review] Firefox patch (trunk and branch both) Checked in on trunk
Reporter | ||
Updated•19 years ago
|
Alias: SA13258
Flags: blocking1.7.5?
Whiteboard: [sg:fix]
Comment 19•19 years ago
|
||
Comment on attachment 168166 [details] [diff] [review] Patch for 1.7 branch a=mkaply for 1.7.5
Attachment #168166 -
Flags: approval1.7.5? → approval1.7.5+
![]() |
Assignee | |
Updated•19 years ago
|
Keywords: fixed1.7.5
![]() |
Assignee | |
Comment 20•19 years ago
|
||
Marking fixed, in fact, since this is now fixed on trunk.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 21•19 years ago
|
||
Comment on attachment 168164 [details] [diff] [review] Firefox patch (trunk and branch both) a=ben@mozilla.org
Attachment #168164 -
Flags: approval-aviary? → approval-aviary+
![]() |
Assignee | |
Comment 22•19 years ago
|
||
fixed-aviary1.0, though it's not fixed in 1.0, of course....
Keywords: fixed-aviary1.0
Comment 23•19 years ago
|
||
1.7.5 has shipped. Moving request to 1.7.6.
Flags: blocking1.7.5? → blocking1.7.6?
Comment 24•19 years ago
|
||
its _in_ 1.7.5 based on keywords, so removing blocking flag.
Flags: blocking1.7.6?
Comment 25•19 years ago
|
||
need to make sure this gets on the right branch
Flags: blocking-aviary1.0.1+
Comment 27•19 years ago
|
||
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
Status: RESOLVED → VERIFIED
Updated•19 years ago
|
Summary: [SA13258] "Save Link As" Download Dialog Spoofing Vulnerability → [SA13258 no rating] "Save Link As" Download Dialog Spoofing Vulnerability
Reporter | ||
Updated•19 years ago
|
Group: security
Comment 28•19 years ago
|
||
Does anyone have a page up with the test case ?
Comment 29•19 years ago
|
||
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.
![]() |
Assignee | |
Comment 30•19 years ago
|
||
> 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•19 years ago
|
||
(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"
![]() |
Assignee | |
Comment 32•19 years ago
|
||
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.
Updated•18 years ago
|
Flags: testcase+
Updated•17 years ago
|
Flags: in-testsuite+ → in-testsuite?
Updated•7 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•