All users were logged out of Bugzilla on October 13th, 2018
Bug 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

RESOLVED FIXED in Firefox 42

Status

()

RESOLVED FIXED
3 years ago
5 months ago

People

(Reporter: jordi.chancel, Assigned: droeh)

Tracking

(Depends on: 1 bug, {csectype-disclosure, sec-moderate})

40 Branch
Firefox 43
csectype-disclosure, sec-moderate
Points:
---
Dependency tree / graph
Bug Flags:
sec-bounty +

Firefox Tracking Flags

(firefox41- wontfix, firefox42+ fixed, firefox43+ fixed, fennec+)

Details

(Whiteboard: [post-critsmash-triage][adv-main42+], URL)

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

3 years ago
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.
(Reporter)

Updated

3 years ago
Summary: file: URIs SOP Bypass: Local private data can be stolen using an automatic download of a html file and interact with this local html file downloaded → 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
(Reporter)

Comment 1

3 years ago
Created attachment 8645985 [details]
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.
(Reporter)

Comment 2

3 years ago
Created attachment 8645991 [details]
TESTCASE1 (wih all file used).zip

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

Comment 3

3 years ago
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
(Reporter)

Updated

3 years ago
Whiteboard: Sensitives files which is downloaded are also accessible in the SD card which its location is world readable (Data theft).
(Reporter)

Updated

3 years ago
Whiteboard: Sensitives files which is downloaded are also accessible in the SD card which its location is world readable (Data theft). → Sensitives files which is downloaded are also accessible in the SD card and its location is world readable (Data theft).
(Reporter)

Updated

3 years ago
Whiteboard: Sensitives files which is downloaded are also accessible in the SD card and its location is world readable (Data theft). → Sensitives files which is downloaded are also accessible in the SD card and its location is world readable (Data theft is possible)
(Reporter)

Comment 4

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

Thanks.
Kevin/Aaron - could one of you give this a try to see if it reproduces?
Flags: needinfo?(kbrosnan)
Flags: needinfo?(aaron.train)

Updated

3 years ago
Flags: needinfo?(aaron.train)
(Reporter)

Updated

3 years ago
Whiteboard: Sensitives files which is downloaded are also accessible in the SD card and its location is world readable (Data theft is possible) → Sensitive file which is downloaded are also accessible in the SD card & its location is world readable. leads to Data theft
(Reporter)

Updated

3 years ago
Whiteboard: Sensitive file which is downloaded are also accessible in the SD card & its location is world readable. leads to Data theft → Sensitives files which is downloaded are also accessible in the SD card and its location is world readable (Data theft is possible)
Version: Firefox 39 → Firefox 40
(Reporter)

Updated

3 years ago
Whiteboard: Sensitives files which is downloaded are also accessible in the SD card and its location is world readable (Data theft is possible) → Sensitive file which is downloaded are also accessible in the SD card & its location is world readable. leads to Data theft
(Reporter)

Comment 6

3 years ago
Vulnerability tested and works also on the new firefox version for Android (Mozilla Firefox 40).
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.
Whiteboard: Sensitive file which is downloaded are also accessible in the SD card & its location is world readable. leads to Data theft
Created attachment 8647614 [details]
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.
Flags: sec-bounty?
(Reporter)

Comment 9

3 years ago
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
(Reporter)

Comment 10

3 years ago
Matt Wobensmith , read comment9 please (it is my answer at your last comment).
Flags: needinfo?(mwobensmith)
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.
Flags: needinfo?(mwobensmith)
(Reporter)

Comment 12

3 years ago
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 )
Flags: needinfo?(mwobensmith)
(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.
Flags: needinfo?(mwobensmith)
(Reporter)

Comment 14

3 years ago
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?
Flags: needinfo?(mwobensmith)
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.
Flags: needinfo?(mwobensmith)
(Reporter)

Comment 16

3 years ago
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.
Flags: needinfo?(mwobensmith)
Flags: needinfo?(mwobensmith)
(Reporter)

Comment 17

3 years ago
(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.
Flags: needinfo?(wkocher)
Flags: needinfo?(wjohnston2000)
Flags: needinfo?(ted)
Flags: needinfo?(sledru)
Flags: needinfo?(ryanvm)
Flags: needinfo?(rnewman)
Flags: needinfo?(rkothari)
Flags: needinfo?(nchen)
Flags: needinfo?(mwobensmith)
Flags: needinfo?(michael.l.comella)
Flags: needinfo?(mgoodwin)
Flags: needinfo?(mark.finkle)
Flags: needinfo?(margaret.leibovic)
Flags: needinfo?(lukasblakk+bugs)
Flags: needinfo?(lhenry)
Flags: needinfo?(jst)
Flags: needinfo?(gpascutto)
Flags: needinfo?(dveditz)
Flags: needinfo?(dbolter)
Flags: needinfo?(continuation)
Flags: needinfo?(cbook)
Flags: needinfo?(catalin.suciu)
Flags: needinfo?(bugmail.mozilla)
Flags: needinfo?(bnicholson)
Flags: needinfo?(bajaj.bhavana)
Flags: needinfo?(alam)
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.
Flags: needinfo?(wkocher)
Flags: needinfo?(wjohnston2000)
Flags: needinfo?(ted)
Flags: needinfo?(sledru)
Flags: needinfo?(ryanvm)
Flags: needinfo?(rnewman)
Flags: needinfo?(rkothari)
Flags: needinfo?(nchen)
Flags: needinfo?(michael.l.comella)
Flags: needinfo?(mgoodwin)
Flags: needinfo?(mark.finkle)
Flags: needinfo?(margaret.leibovic)
Flags: needinfo?(lukasblakk+bugs)
Flags: needinfo?(lhenry)
Flags: needinfo?(jst)
Flags: needinfo?(gpascutto)
Flags: needinfo?(dveditz)
Flags: needinfo?(dbolter)
Flags: needinfo?(continuation)
Flags: needinfo?(cbook)
Flags: needinfo?(catalin.suciu)
Flags: needinfo?(bugmail.mozilla)
Flags: needinfo?(bnicholson)
Flags: needinfo?(bajaj.bhavana)
Flags: needinfo?(alam)
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 hidden (obsolete)
Comment hidden (obsolete)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) 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.
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?
>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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
As rnewman pointed out, this looks like it's caused by regressing bug 945429.
..and that bug explains why it doesn't work on desktop :-P
tracking-fennec: --- → ?
(Reporter)

Comment 27

3 years ago
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.
(Reporter)

Updated

3 years ago
Blocks: 945429
(Reporter)

Comment 28

3 years ago
Like Gian-Carlo Pascutto had said in the Comment25 , I've marked/indicated in the block informations : the bug 945429 .
Flags: needinfo?(mwobensmith)
Flags: needinfo?(kbrosnan)
Keywords: csectype-other, sec-moderate
(Reporter)

Comment 29

3 years ago
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.
Flags: needinfo?(dveditz)
Assignee: nobody → droeh
tracking-fennec: ? → +
Mike might be able to help with this too.
Flags: needinfo?(michael.l.comella)
Flags: needinfo?(dveditz)
Keywords: csectype-other → csectype-disclosure

Updated

3 years ago
Group: core-security → firefox-core-security
(Assignee)

Comment 31

3 years ago
Created attachment 8658362 [details] [diff] [review]
Proposed patch

Here's a proposed patch that simply disables all file:// downloads on Android.
Attachment #8658362 - Flags: review?(snorp)
Attachment #8658362 - Flags: review?(snorp) → review+
Approach in comment 31 seems reasonable - NI me if you need me again.
Flags: needinfo?(michael.l.comella)
We may want to uplift this to at least 42. May be a bit late for beta.
status-firefox41: --- → affected
status-firefox42: --- → affected
status-firefox43: --- → affected
tracking-firefox41: --- → ?
tracking-firefox42: --- → +
tracking-firefox43: --- → +
(Assignee)

Updated

3 years ago
Keywords: checkin-needed

Updated

3 years ago
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/0c24126a81e5
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox43: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 43
Attachment #8645991 - Attachment mime type: application/zip → application/java-archive
Flags: sec-bounty? → sec-bounty+
Group: firefox-core-security → core-security-release
(Assignee)

Comment 37

3 years ago
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
Attachment #8658362 - Flags: approval-mozilla-aurora?
Comment on attachment 8658362 [details] [diff] [review]
Proposed patch

Let's take it before 42 goes in beta.
Attachment #8658362 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Unless I am told otherwise by sec team, it is already too late to take this in 41.
status-firefox41: affected → wontfix
tracking-firefox41: ? → -
(Reporter)

Comment 41

3 years ago
Created attachment 8667857 [details]
PoC n°2 (works with Firefox 41).zip
Attachment #8645991 - Attachment is obsolete: true
(Reporter)

Updated

3 years ago
Attachment #8645991 - Attachment is obsolete: false
(Reporter)

Updated

3 years ago
Attachment #8667857 - Attachment is obsolete: true
Whiteboard: [post-critsmash-triage]
Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][adv-main42+]
Alias: CVE-2015-7186
(Reporter)

Comment 42

3 years ago
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
Flags: needinfo?(chofmann)
Flags: needinfo?(abillings)
Jordi, for the 100th time, use email, not bugzilla, for questions.
Flags: needinfo?(chofmann)
Flags: needinfo?(abillings)
Group: core-security-release

Updated

5 months ago
Depends on: 1282623
You need to log in before you can comment on or make changes to this bug.