762705 - misleading download URI listed when downloading a file from a nested URI (e.g. view-source:)

Status: RESOLVED FIXED

(Firefox :: File Handling, defect)

Description

[Soroush Dalili]

Attachment: mozFileDownloadSourceSpoof.html

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.52 Safari/536.5

Steps to reproduce:

I am using the following techniques to hide the source of an executable file which is downloaded:
1- "alert" box in "onbeforeunload" to create a delay
2- loading a legitimate page such as Mozilla download page in "onbeforeunload" 
3- loading a fake executable file as the destination of the page
4- use "view-source:" protocol in front of the downloadable file to hide the download source ("view-source:http://0me.me/fake/calc.php")
5- "Content-Type: application/octet-stream" can be downloaded even via "view-source:" protocol.
6- user "Worker" to create "alert" boxes without having the "do not show again" option.
7- loading the destination page in an image tag to be cached; to reduce the loading time.

As a result it opens the download panel in front of the legitimate website.

In the following PoC, I have used "cmd.exe" which has renamed to "Firefox Setup.exe":
http://0me.me/demo/mozilla/firefox/mozFileDownloadSourceSpoof.html

I will attach this file here as well.



Actual results:

a download panel will opened in front of the "Mozilla Firefox" download website. Its source has been set to "view-source:". 


Expected results:

1- download panel should not be opened in front of another page in another website
2- its source should be equal to the real source
3- "view-source" should not download the file
4- "alert" boxes via Worker, should also have the hide option.

Comment 1

[Soroush Dalili]

Attachment: requirement for the html file

Comment 2

[Soroush Dalili]

Attachment: PoC result image

Comment 3

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

This is essentially bug 741050, though with the added twist of using view-source: to mask the true download source in the dialog.

"use a worker to bypass the dialog limit protection" should be filed as a separate bug, since AFAICT it's not really related to this at all.

Comment 4

[Soroush Dalili]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #3)
> This is essentially bug 741050, though with the added twist of using
> view-source: to mask the true download source in the dialog.

1) I am using "onbeforeunload", but in bug 741050, it uses "setTimeout". 2) This one opens in the same window and does not need to open a new window and you do not need to keep both of windows open at the same time (741050 does). 3) as you said, this one hides the source as well

> "use a worker to bypass the dialog limit protection" should be filed as a
> separate bug, since AFAICT it's not really related to this at all.

Do you want me report it as a normal bug or a security issue?

Comment 5

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

A normal bug would be fine.

Comment 6

[Al Billings [:abillings - ex-MoCo]]

Nice. Marking confirmed.

Comment 7

[Soroush Dalili]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #5)
> A normal bug would be fine.
I cannot create a reliable PoC for this alert messages; I guess I could just use a normal alert in for loop (not from worker) in the first example (I cannot remember why I went through that way)

Comment 8

[Daniel Veditz [:dveditz]]

Pretty sure fixing the underlying issues in bug 741050 will address this, but we'll leave it open to re-test.

Comment 9

[Soroush Dalili]

Could you please let me know if this can be eligible for the bug bounty program?

Comment 10

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

Attachment: WIP

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #3)
> This is essentially bug 741050, though with the added twist of using
> view-source: to mask the true download source in the dialog.

This is a WIP patch to fix the "added twist" part.

Comment 11

[Soroush Dalili]

(In reply to Daniel Veditz [:dveditz] from comment #8)
> Pretty sure fixing the underlying issues in bug 741050 will address this,
> but we'll leave it open to re-test.

As the other issue is already public, am I allowed to publish this one too?

Comment 14

[Daniel Veditz [:dveditz]]

(In reply to Soroush Dalili from comment #11)
> As the other issue is already public, am I allowed to publish this one too?

We'd prefer not, but you can do so if you feel strongly enough.

Gavin: where did this break down? Your WIP patch is a couple months old.

The PoC in the bug doesn't seem to work on Nightly (FF19), probably by accident. Instead of getting a download I get the executable shown as text in a view-source window. Testcase still reproduces on Aurora (FF18) so it was something changed since Oct 8. I don't see any changes to the view-source channel or protocol handler in that time, maybe it's in document navigation?

Bug 741050 "works" fine (reproduces) in Nightly so it's curious, but you can still work around it. jar: seems to work, for example replace the view-source URL with 

jar:https://bug267123.bugzilla.mozilla.org/attachment.cgi?id=168128!/SA12979_2/2a/poc.php

Comment 15

[Daniel Veditz [:dveditz]]

Attachment: updated mozFileDownloadSourceSpoof.html for FF19

This isn't as good as the original view-source testcase because I reused an existing jar file, but it would be trivial in a real attack to make it say "Firefox Setup.exe" as expected.

Comment 16

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

My patch only fixes the "from:" label in the dialog that appears, it doesn't attempt to address the broader issue raised by bug 741050.

Comment 17

[Daniel Veditz [:dveditz]]

Similarly Chris McGowen reported bug 739172

Comment 18

[Soroush Dalili]

Can I have access to "bug 739172" please?

Comment 19

[Al Billings [:abillings - ex-MoCo]]

(In reply to Soroush Dalili from comment #18)
> Can I have access to "bug 739172" please?

Done.

Comment 20

[Soroush Dalili]

Any update on this?

Comment 22

[Al Billings [:abillings - ex-MoCo]]

Gavin, can we find someone to work on this? I see you were asked the same thing in bug 741050.

Comment 23

[Drew Willcoxon :adw]

Comment on attachment 649433 [details] [diff] [review]
WIP

This patch satisfies this bug in the case of nested URIs like jar and view-source, but not necessarily for URIs with nondescript prepaths like data URIs.  If you modify the proof of concept to use a data URI, the "from:" field still shows "data:".  But what should it show?

Also, what if I write a malicious extension that handles URIs with scheme foo, so that I control URIs like foo:http://www.mozilla.org/firefox/download?  With this patch, the user would see www.mozilla.org, but that's not what he's getting.  Is that something to worry about?

Why not just show the full URI of the download (in a scrollable, non-editable text area for example)?

Comment 24

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

I think showing just "data:" for data URIs is fine. Alternatively, if the URI type has no hostname (i.e. its prePath will be unusual), we can just show the entire URI (and probably truncate it at the end or in the middle).

Re: other arbitrary nested URIs, the goal is to show the origin of the data, and it's generally a safe assumption that that's represented by innermost URI, so I don't think that's a huge concern. But downloading things from nested URIs is an edge case to begin with, so if we want to just bail in that case and display the full URL or something like that, I think that's fine too.

Comment 25

[Drew Willcoxon :adw]

Comment on attachment 649433 [details] [diff] [review]
WIP

In that case, here's a semi-unsolicited r+, since the patch looks fine to me and it works.

Comment 26

[Drew Willcoxon :adw]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b265662ba653

Comment 27

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/b265662ba653