1193027 - (CVE-2015-7186) file: URIs SOP Bypass: Local private data into the local firefox folder "file:///(...)/cache/[*******].default/cache2/entries/" can be stolen using an automatic download of a html file and interact with this html file downloaded

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Jordi Chancel]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150630154324

Steps to reproduce:

With firefox for Android it's possible to download automaticly an html file with normal configuration using a PHP remote file.
When you go on the HTML file automaticly downloaded and interact with it , 
it's possible to steal private data into the local firefox folder : "file:///data/data/org.mozilla.firefox/cache/[*******].default/cache2/entries/"  which contains sensitive data like partial or full content of a website visited, 
token verification key , 
what the user has searched on google or other website (showed in the demonstration video that i will uploaded), 
and very much others private data which can lead to very confidential data stealing.

This sensitive data stealing is possible because when you download a file which is into the firefow folder : "file:///data/data/org.mozilla.firefox/cache/[*******].default/cache2/entries/" , 
it is downloaded into the download folder and canbe read by an html file and sent on a malicious website scheduled to save data sent on this website.

I have tested this vulnerability on a Samsung Galaxy S5 4g+ Lolipop Android version 5.0.2 and a Samsung Galaxy Tab A Lolipop version 5.0.2 with the last public version of Firefox for Android : Firefox 39.0
I will upload a video for show you how to interact with the testcase.


Actual results:

Very sensitive data into the local firefox folder "file:///data/data/org.mozilla.firefox/cache/[*******].default/cache2/entries/"  can be stolen leading to private data theft.


Expected results:

All files into the the local folder "file:///data/data/org.mozilla.firefox/cache/[*******].default/cache2/entries/" should not be downloaded into the download folder because this can lead to sensitive data stealing.

Vulnerability bug reported by Security researcher Jordi Chancel.

Comment 1

[Jordi Chancel]

Attachment: Video-Example n°1 (Steps to reproduce in this video).html

With this video you can view all steps needed for the working of this vulnerability.

Comment 2

[Jordi Chancel]

Attachment: TESTCASE1 (wih all file used).zip

This ZIP file contains all file used by the TESTCASE showed in the demonstration video uploaded.

Comment 3

[Jordi Chancel]

Sensitives files which is downloaded are also accessible in the SD card and the SD card location is world readable which can lead to an information disclosure.


-----

(1): The 1st HTML will be automaticly downloaded.

(2): The 1st HTML file automaticly downloaded will downloaded the 2nd HTML file (automaticly too) and an HTML redirection will redirect the user on this 2nd HTML file.

(3): The 2nd HTML file will downloaded the 3rd HTML file (automaticly too) and an HTML redirection will redirect the user on this 3rd HTML file.

-----

The 1st HTML file is a ClickJacking which leads to go on the sensitive folder for/and download a sensitive file.

The 2nd HTML file lead to download again the sensitive file (allready downloaded) with a readable extention (eg: sensitivefile1.txt).

The 3rd HTML file will load the content of this readable file and send it on a malicious website.

-----

TESTCASE into the zip file [ TESTCASE1 (wih all file used).zip ] in the report attachment : https://bugzilla.mozilla.org/attachment.cgi?id=8645991

Comment 4

[Jordi Chancel]

You can directly use the testcase in my website : https://www.alternativ-testing.fr/hack0.php with Mozilla Firefox for Android.

Thanks.

Comment 5

[Matt Wobensmith [:mwobensmith][:matt:]]

Kevin/Aaron - could one of you give this a try to see if it reproduces?

Comment 6

[Jordi Chancel]

Vulnerability tested and works also on the new firefox version for Android (Mozilla Firefox 40).

Comment 7

[Matt Wobensmith [:mwobensmith][:matt:]]

From whiteboard:
"Sensitive file which is downloaded are also accessible in the SD card & its location is world readable. leads to Data theft"

Do not enter data into this field. Leave it as a comment instead. Thank you.

Comment 8

[Matt Wobensmith [:mwobensmith][:matt:]]

Attachment: Screenshot_2015-08-13-10-36-24.png

Jordi, I am trying to reproduce this, but it does not make sense. I am attaching a screen shot of the final page that is loaded with your instructions. 

Your scenario involves many timed clicks, which seems possibly prone to error. Can you try to create a better example that involves minimal user interaction? Thank you.

Comment 9

[Jordi Chancel]

Reply to the comment8 by Matt Wobensmith :


Yes but you have executed the poc on the folder : "file:///storage/emulated/0/download/" and the TESTCASE is coded to work in the folder :"file:///storage/emulated/legacy/download/" , but another TESTCASE can be coded for work with the folder that you had used(file:///storage/emulated/0/download/).

Please try the TESTCASE on the folder "file:///storage/emulated/legacy/download/" , 

or if you want i can code a new TESTCASE for be executed on the folder : "file:///storage/emulated/0/download/" .

And please, look the demonstration video {Video-Example n°1 (Steps to reproduce in this video).html} in the attachments : https://bugzilla.mozilla.org/attachment.cgi?id=8645985 for know how works the TESTCASE  .


And excepted the first HTML file automatically downloaded which use a clickjacking attack , all others steps in the others HTML files automatically downloaded can be automated without user interaction.


I want add a remark about the file stolen, downloaded in the folder : "file:///storage/emulated/legacy/download/" , actually the TESTCASE is coded for only steal a file with its name which starts by the number "0" (because the first HTML file automatically downloaded which use a clickjacking attack tries to download a file in the beginning of the sensitive folder (which so has a lot of chance to start by the number "0") but another testcase can be coded for steal content of others files downloaded in the sensitive firefox folder (already cited in the start of this comment), with a different number or  a different character at the beginning of name of the  possibly sensitive file which is downloaded in the download folder.


Matt Wobensmith , say me if you have again a problem with the testcase.

Thanks

Comment 10

[Jordi Chancel]

Matt Wobensmith , read comment9 please (it is my answer at your last comment).

Comment 11

[Matt Wobensmith [:mwobensmith][:matt:]]

I've watched the video, but either I'm doing the steps wrong or it's not working. It is up to you to create a working exploit that is easy to understand, reliable and foolproof. If I cannot see an issue, then I am not convinced that our users will see one either. I would recommend creating something with far less steps. Thank you.

Comment 12

[Jordi Chancel]

For the moment , please try the testcase in executing the TESTCASE in the download folder : "file:///storage/emulated/legacy/download/" and NOT the folder : "file:///storage/emulated/0/download/" .

I have tested this Testcase on multiple Android device and it works verry well (even if the actual testcase require a lot of steps).

When you have exploited perfectly the actual testcase (always by looking the demonstration video in the attachments for view all steps needed) i will code a better testcase with less user interaction ( i.e. : no user interaction in the 2nd and the 3rd HTML file automatically downloaded used by the TESTCASE )

Comment 13

[Matt Wobensmith [:mwobensmith][:matt:]]

(In reply to Jordi Chancel from comment #12)
> For the moment , please try the testcase in executing the TESTCASE in the
> download folder : "file:///storage/emulated/legacy/download/" and NOT the
> folder : "file:///storage/emulated/0/download/" .
> 
> I have tested this Testcase on multiple Android device and it works verry
> well (even if the actual testcase require a lot of steps).
> 
> When you have exploited perfectly the actual testcase (always by looking the
> demonstration video in the attachments for view all steps needed) i will
> code a better testcase with less user interaction ( i.e. : no user
> interaction in the 2nd and the 3rd HTML file automatically downloaded used
> by the TESTCASE )


I have already spent a fair bit of time on this, without results. I will wait for a better test case. Thank you.

Comment 14

[Jordi Chancel]

For the bug1149000 you had also difficulty to reproduce what i demonstrated and another man in the CC'list has finally approved the vulnerability that i had  demonstrated. it is possible that another code is needed for the Android device that you use.

So please, can you ask to some people which have a Samsung Galaxy S5 or a Samsung Galaxy Tab A or another recent samsung device for test the actual TESTCASE please?

Because when i look your screenshot , to code a testcase with less user interaction on the testcase (that i use), which will be used on your Android device can't allow a reproduction  (excepted if it can works with your Android device but you use the testcase on the wrong download folder).


If you want i can try to code a testcase for your download folder "file:///storage/emulated/0/download/" and you will see if it works with this folder?


But if someone can try with a Samsung Galaxy S5 Lolipop Android version 5.0.2 
or 
a Samsung Galaxy Tab A Lolipop Android version 5.0.2
or another Samsung recent device (phone or tablet) i'm sure that it will reproduce all steps perfectly and confirmed that the testcase works like described?

Comment 15

[Matt Wobensmith [:mwobensmith][:matt:]]

I have a Nexus 5 running Lollipop. If you want to make a test case that works on that phone, I'd be happy to try it. However, I don't have access to the other phones you describe, so I can't be of help there.

Comment 16

[Jordi Chancel]

Ok but i have not a Nexus 5 , and if you can ask to some men of Mozilla if they have a "Samsung Galaxy s5 Lollipop" or "Samsung Galaxy Tab A Lollipop" preferably or others recent Samsung Lollipop devices , they can help very much to reproduce the steps of testcase.

(23h15 french hour) i will continu to comment and help on this report tomorow.

Comment 17

[Jordi Chancel]

(Read completely this comment please , thanks.)

I need that all people to whom I send a NEEDINFO request to TEST the TESTCASE (.ZIP file) in the Attachments , preferably with : "Samsung Galaxy s5 Android lollipop 5,0,2" 
or 
"Samsung Galaxy Tab A Android Lollipop version 5,0,2" , 
or 
a "recent Samsung device with Android Lollipop version" by default if you don't have of the two android device cited because my testcase works perfectly on a "Samsung Galaxy s5 Android Lollipop" and a "Samsung Galaxy Tab A Android Lollipop".


For look all steps needed, please look the demonstration video in the attachments :  Video-Example n°1 (Steps to reproduce in this video).html => https://bug1193027.bmoattachments.org/attachment.cgi?id=8645985 .

You must execute the First HTML file automatically downloaded in the folder : "file:///storage/emulated/legacy/download/" ,  and never the other download folder : "file:///storage/emulated/0/download/" because the TESTCASE used in the attachments is coded for be executed in the folder "file:///storage/emulated/legacy/download/" (even if another TESTCASE can be coded for be executed on the other download folder).

I want add an important remark about the possible sensitive file downloaded into the sensitive folder : "file:///data/data/org.mozilla.firefox/cache/[*******].default/cache2/entries/" destined to be downloaded in the download folder must have its name which starts by the number "0" (if the name of the sensitive file downloaded have a name starting by another number or another character (even if another testcase can be coded to the stealing sensitive file downloaded with a name starting by another number (1 ; 2 ;3; ...) or another character (A ; B ; C ; ...) ) (view demonstration video for better understand what i want explain)


Thanks at all for your next help.

Comment 18

[Andrew McCreight [:mccr8]]

Jordi, please do not needinfo more than one or two people at a time. Try to figure out who can help you and needinfo them, and if they can't, then try somebody else. I've left the needinfo up for a few of our QA people are removed the rest.

Comment 19

[Gian-Carlo Pascutto [:gcp]]

Also note that needinfo-ing people on this bug makes it visible to them. Not all the people you needinfoed normally have access to security bugs and some don't even work for Mozilla!

>It is up to you to create a working exploit that is easy to understand, reliable and foolproof.

Whoa, that's worded in a rather unfortunate manner! There's no requirement to provide a PoC for vulnerabilities you find. However, we must obviously be able to verify the vulnerability exists and right now I'm not sure I understand the explanation and we can't seem to get the PoC working.

I'm going to take a look a the files in the ZIP to see if I can understand what the vulnerability actually *is*.

Comment 20

[Kartikaya Gupta (email:[e-mail])]

I took a look at the zip file also. It seems like the "vulnerability" requires the user to manually open a file from the Downloads/ folder in the browser. That file can then access other file:/// URIs including stuff from the Firefox cache.

I'm not sure if this qualifies as a legitimate vulnerability, but somebody from the security team should make the call. It's equivalent to saving this file to your local hard drive and then opening it in the browser:

<iframe src="my.passwords.file" onload="document.getElementById('x').textContent = window[0].document.documentElement.textContent" style="visibility:hidden"></iframe>
I stole your passwords file: <div id="x"></div>

Comment 21

[Kartikaya Gupta (email:[e-mail])]

(For the record, the video attached by the reporter has this initial click at 30 seconds in. All the rest of the clicks and process is probably unnecessary; the end result is that files from the Firefox cache can be stolen if the user does this initial click).

Comment 22

[Gian-Carlo Pascutto [:gcp]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #20)
> I took a look at the zip file also. It seems like the "vulnerability"
> requires the user to manually open a file from the Downloads/ folder in the
> browser. That file can then access other file:/// URIs including stuff from
> the Firefox cache.

That's a SOP violation. file:// URI's are only supposed to access same dirs and subdirs. The cache dir sits nearer to the root compared to the Downloads dir, so it shouldn't be accessible.

This seems to reproduce on my Nexus 7 on Android 5.1.1.

>This sensitive data stealing is possible because when you download a file which is into the firefow folder 
>: "file:///data/data/org.mozilla.firefox/cache/[*******].default/cache2/entries/" , 
>it is downloaded into the download folder and canbe read by an html file and sent on a malicious website 
>scheduled to save data sent on this website.

So, SOP for file:// is same dir and subdirs. This means that a downloaded file has no way to access cache2/entries because that's in a different dir higher up. You say you're working around this by downloading the file from cache2/entries into Downloads, at which point any previously downloaded file would be in the same dir and the SOP would no longer apply.

I think I understand how it works now: once you downloaded the file, you are able to show the file://data/data/org.mozilla.firefox/cache/ stuff in an iframe. You then use clickjacking to make the user descend into the actual profile dir, bypassing the salting of same. (That's why all the settimeout and positioning stuff is in there - this step is critical for it to be a usable exploit!)

You then retrieve the location of the iframe, which you're allowed to do because?? (I'm guessing a subdir of the original file:// path is allowed or something? Not being able to get the current URL of an iframe is considered security sensitive and this bug show why)

Now you've got a full bypass of our salting, and know exactly which file to download. Boom! The rest is irrelevant.

This looks legit to me.

Comment 23

[Gian-Carlo Pascutto [:gcp]]

What's stopping this from working on desktop? I guess the problem is that you can't guess where to start the file:// URL because the users name sits ahead of the cache dir in the path, and you need a dependable directory structure to do the clickjacking reliably?

What about accounts that are just named Administrator?

Comment 24

[Gian-Carlo Pascutto [:gcp]]

>You then retrieve the location of the iframe, which you're allowed to do because??

Upon looking closer, that's not how it works.

I think you're simply allowing the user to click on the file. Which then causes us to download it.

Comment 25

[Gian-Carlo Pascutto [:gcp]]

As rnewman pointed out, this looks like it's caused by regressing bug 945429.

Comment 26

[Gian-Carlo Pascutto [:gcp]]

..and that bug explains why it doesn't work on desktop :-P

Comment 27

[Jordi Chancel]

Thank you very much Gian-Carlo Pascutto for have confirmed this security bug and confirm that it is a SOP Violation/Bypass (it is what i had written in the title of this report).

I want add that : excepted the first HTML file automatically downloaded which use a ClickJacking Attack, the two others HTML files automatically downloaded can be modified for that the user interactions used are replaced by others code which will automate all action used by these HTML files.

Comment 28

[Jordi Chancel]

Like Gian-Carlo Pascutto had said in the Comment25 , I've marked/indicated in the block informations : the bug 945429 .

Comment 29

[Jordi Chancel]

Daniel, You've writed in the Keywords: csectype-other.

But I think that like bug945429  , this vulnerability (which is a regression of bug945429 with a more or less similar impact : vulnerability of Data Theft ) can be defined like csectype-disclosure (like i really think it's the case)? 
If you are alright ,of course.

Comment 30

[Mark Finkle (:mfinkle) (use needinfo?)]

Mike might be able to help with this too.

Comment 31

[Dylan Roeh (:droeh) (he/him)]

Attachment: Proposed patch

Here's a proposed patch that simply disables all file:// downloads on Android.

Comment 32

[Dylan Roeh (:droeh) (he/him)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=680c9b538119

Comment 33

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Approach in comment 31 seems reasonable - NI me if you need me again.

Comment 34

[Liz Henry (:lizzard) (relman/hg->git project)]

We may want to uplift this to at least 42. May be a bit late for beta.

Comment 35

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/integration/fx-team/rev/0c24126a81e5

Comment 36

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/0c24126a81e5

Comment 37

[Dylan Roeh (:droeh) (he/him)]

Comment on attachment 8658362 [details] [diff] [review]
Proposed patch

Approval Request Comment
[Feature/regressing bug #]: 945429
[User impact if declined]: Possible profile data leakage
[Describe test coverage new/current, TreeHerder]: https://treeherder.mozilla.org/#/jobs?repo=try&revision=680c9b538119
[Risks and why]: Low-risk; disables download of file:// urls on Android, which doesn't have any clear use case.
[String/UUID change made/needed]: N/A

Comment 38

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8658362 [details] [diff] [review]
Proposed patch

Let's take it before 42 goes in beta.

Comment 39

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Unless I am told otherwise by sec team, it is already too late to take this in 41.

Comment 40

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/21486457a5bd

Comment 41

[Jordi Chancel]

Attachment: PoC n°2 (works with Firefox 41).zip

Comment 42

[Jordi Chancel]

There is an error of writing in the MFSA 2015-120 -> https://www.mozilla.org/en-US/security/advisories/mfsa2015-120/

in the advisory we read : Security researcher Jordi Chancel reported an issue in Firefox for Android where a locally saved HTML file could use file:>/code> URIs to trigger the download of additional files or opening of cached profile data without user awareness.


>/code> HTML code is wrongly written and must be written </code>

Can you make the correction in this description of this vulnerability please?

Thanks

Comment 43

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

Jordi, for the 100th time, use email, not bugzilla, for questions.