User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.80 Safari/537.36

Steps to reproduce:

STEP TO REPROCUDE

1. Upload all the files from zip to your server
2. Edit files - replace attacker.domain with your server domain
3. Add a small image (<2kb, max 50x50) in /sdcard/Download/test.jpeg [I have used this path because it is easy and I have used a little image because so the code of the proof of concept is easy, but it is possible to replicate with every image]
4. With Firefox 67.0 open attacker.domain/test.html
5. Firefox will download the file payload.html and will save it in /sdcard/Download (by default)
6. Open with Firefox the downloaded file payload.html and wait some seconds
7. The base64 string of test.jpeg should be in image.txt

Tested on Samsung Galaxy S6 with Android 7.0 and Firefox 67.0

In the PoC.zip you find:

• test.html
• download.php, that downloads the file payload.html
• the malicious file payload.html
• base64.php to convert an image into base64 and steal it

Sorry for my english.

Actual results:

It is possible to steal files from sdcard, in particular it is easy to steal the images. In my opinion it is a serious problem because it is really easy to find some paths (e.g. /sdcard/Whatsapp/Media/WhatsApp Images/ and the images have easy name: IMG-AAAAMMDD-WAXXXX.jpg where XXXX is a number like 0000, 0001, and so)

Expected results:

In Chrome, or Microsoft Edge, or Samsung Browser this doesn't append because there is a different Same Origin Policy. I think that it is important, because it is possible to receive an HTML file in a chat (like WhatsApp), download it and open it with Firefox. So in my opinion this is a bug.

Ok, the HTML file can to access only in the dir where it is, so sorry for this.

I'm very confused, I don't know if it is a bug or not. Firefox works like it says: https://developer.mozilla.org/en-US/docs/Archive/Misc_top_level/Same-origin_policy_for_file:_URIs

So if I have a file HTML [ index.html ] in a directory, this file can access to all files in this directory and in any subdirectory. So, if my file index.html is in /sdcard/Download and I have another file bar.html in /sdcard/Download/subdir/, a frame in index.html can load bar.html. This is ok, but it is a problem with WhatsApp (but I think also with other Android apps).

Scenario:

Attacker sends payloadWA.htm to victim via WhatsApp. Victim opens it with Firefox, and Firefox helps to steal the victim's sent documents via WhatsApp. Why does this happen? Because WhatsApp is really well-ordered.

1. Attacker sends payloadWA.htm to victim.
2. VIctim downloads it to open it with Firefox.
3. payloadWA.htm is saved in /sdcard/WhatsApp/Media/WhatsApp Documents/payloadWA.htm
4. In the last path there is a subdirectory named "Sent" where there are all documents sent by the victim via WhatsApp and their names are really easy: DOC-YYYYMMDD-WAXXXX.ext, where YYYY is year, MM is month, DD is day, XXXX is a ordered number (like 0000, 0001, 0002, etc) and ext is the extension.
5. Now, the victim opens payloadWA.htm with Firefox. FIrefox doesn't open /sdcard/WhatsApp/Media/WhatsApp Documents/payloadWA.htm but creates a mirror in /data/user/0/org.mozilla.firefox/cache/contentUri and opens the file from this path (at least, that's how it is on my phone)
6. The attacker knows that where is the original payloadWA.htm so it is easy to do a redirect to the original, then steal the files in /Sent/ via XMLHttpRequest.

I hope I have explained myself clearly. It's like the original situation, except that in Download I may not know the names of the various files, in the WhatsApp folders it is easy to guess these names. So is it a bug or is it a feature? I have tested on my Samsung Galaxy S6 / Android 7.0. If it is a bug or vulnerabily, sorry for the report.

And sorry for my English.

Hi, I think this duplicate ticket is important. I write this proof of concept privately because I think it's serious, and I hope someone fixes the issue.

Scenario
The victim has got an Androd phone, where there are installed WhatsApp and Firefox. Firefox is the victim's default browser. To see a received file on WhatsApp you have to download it and save it on your storage. In Android, WhatsApp saves all data in the path /sdcard/WhatsApp/Media, where there are different subdirectories. For example, the received documents via WhatsApp are saved in /sdcard/WhatsApp/Media/WhatsApp Documents/, the sent documents are saved in /sdcard/WhatsApp/Media/WhatsApp Documents/Sent/. Now, the received documents are saved with their original name, so if a contact sends to you a file called document.pdf you will find it in /sdcard/WhatsApp/Media/WhatsApp Documents/document.pdf. Instead the sent documents are stored in the subdirectory Sent with another name, and WhatsApp chooses this name by following an easy schema: DOC-YYYYMMDD-WAXXXX.ext, where YYYYMMDD is the date you have sent the document, XXXX is a ordered number (as 0000, 0001, 0002, etc) and ext is the extension of the file, it is not usually changed by WhatsApp. So it is a neat environment.

Proof of Concept

1. The attacker creates a server, where the victim's data will be sent. In this server they put the two files base64.php and image.txt
2. The attacker sends to the victim the malicious HTM file PoCfinale.htm via WhatsApp
3. The victim opens it with Firefox, and Firefox runs the code
4. PoCfinale.html steals the data in the subdirectory /Sent/, by converting them in base64
5. The data are sent to the attacker's server as base64 strings and stored in image.txt
6. The attacker uses PoC.py to convert the data stored in image.txt into PDF

Attachments

1. Poc.zip, where you can find there files: PoC.py, to convert the data stored in image.txt into PDF, image.txt, base64.php, test1.pdf and PoCfinale.htm, the malicious payload. In the PoCfinale.htm there are four variables: yyyy, mm, dd and h. So if you want to steal the first five victim's sent documents in the date 2019/06/29 (YYYY/MM/DD) you have to set the HTM file with these variable: yyyy = '2019', mm = '06', dd = '30' (your day +1) and h = 4.
2. A video proof-of-concept

How to reproduce

1. You put in your server the base64.php and image.txt
2. With the victim's phone you send the file test1.pdf to someone (I suggest to send it like first document of the day, so in the name there will be WA0000 and so you can set the parameter h equal to 1)
3. With the attacker's phone you send PoCfinale.htm to the victim, and you open it using Firefox on the victim's phone
4. Using PoC.py to decode the file image.txt

I hope to have been clear, I think it is a serious problem, in my example there is WhatsApp, but probabily it is reproduced with other apps that store data in similar way. I have not tested this bug with a SVG file, but I think it can work. The ticket 803143 is very old, I think that someone can have used this bug in the past, so I think it can be useful say to not open HTM file received via WhatsApp with Firefox.

Sorry for my English.
Best regards

Re-opening to better track this scenario for testing when we do fix bug 1500453

Patch now, please.
https://amp.thehackernews.com/thn/2019/07/firefox-same-origin-policy-hacking.html

Changing the security group to allow a bit more visibility

Does this bug affect all GeckoView-powered apps (like Fenix) or only Fennec? Adding whiteboard tag [geckoview:fenix] so the GeckoView team will triage this bug.

Fenix is unaffected as it uses a whitelist of protocols it registers. It only accepts http and https:

We'll want to uplift this fix to Fennec 68 ESR.

I wrote a patch that introduces a pref to treat file: URLs as unique origins. This is just a temporary fix and we can enable the pref just on android.
It will probably break some tests. I'm waiting for this try push: https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=254743572&revision=e40d5711c5f75c35539ecf5490e5ddf9b8ecc117

(In reply to Andrea Marchesini [:baku] from comment #12)

I wrote a patch that introduces a pref to treat file: URLs as unique origins. This is just a temporary fix and we can enable the pref just on android.
It will probably break some tests. I'm waiting for this try push: https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=254743572&revision=e40d5711c5f75c35539ecf5490e5ddf9b8ecc117

Baku, by now I actually think it's a good idea to introduce that pref but flip it all for all platforms, not just Android. Can you please update the patch and re-flag for review?

Sure.

Note from baku regarding loss of web dev test functionality caused by this patch: security.fileuri.strict_origin_policy is a pref that, if set to false, makes all the file: URLs be same-origin. By default this pref is set to true. If web-developers have issue with that patch, they can set that pref to 'false'.

Ok, it breaks just 1 test. Patch updated. Ready to land.

Cfg

With my patch enabled, the STR to test it is the following:
Create 2 files in the same folder.

1. a.html:

<script>

console.log(1);
try {
console.log(2);
  let a = new Worker('a.js');
  a.onerror = e => { console.log(e); }
  console.log(3);
} catch(e) { console.log("AA", e); }
</script>

2. a.js:

console.log("WHAT?!?");

Run file:///the/path/of/a.html
In the console you should not see 'WHAT?!?'. Instead "AA something" is good.
If you set the pref privacy.file_unique_origin to false, you should see 'WHAT?!?'

Comment on attachment 9075974 [details]
Bug 1558299 - Add a pref to treat File: URLs as unique origins, r?ckerschb

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: File: URLs treated as same origins cause an important security issue as this bug shows.
• User impact if declined: see the description of this bug and the following comments
• Fix Landed on Version: 69
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This patch has been discussed a lot and we decide that we want to have this patch in ESR68. The risk is low because other browsers have a similar behavior. Plus, we have a pref to restore the previous value if needed: nprivacy.file_unique_origin
• String or UUID changes made by this patch: none

Beta/Release Uplift Approval Request

• User impact if declined: See the rest of this comment
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: STR in a previous comment
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): See above.
• String changes made/needed: none

(In reply to Andrea Marchesini [:baku] from comment #19)

Comment on attachment 9075974 [details]
Bug 1558299 - Add a pref to treat File: URLs as unique origins, r?ckerschb

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: File: URLs treated as same origins cause an important security issue as this bug shows.
• User impact if declined: see the description of this bug and the following comments
• Fix Landed on Version: 69
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This patch has been discussed a lot and we decide that we want to have this patch in ESR68. The risk is low because other browsers have a similar behavior. Plus, we have a pref to restore the previous value if needed: security.fileuri.strict_origin_policy
• String or UUID changes made by this patch: none

Beta/Release Uplift Approval Request

• User impact if declined: See the rest of this comment
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: STR in a previous comment
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): See above.
• String changes made/needed: none

https://hg.mozilla.org/integration/autoland/rev/2ad059cc9e78

Comment on attachment 9075974 [details]
Bug 1558299 - Add a pref to treat File: URLs as unique origins, r?ckerschb

Fixes a public security issue. Approved for 68.0-build3 and 68.0esr-build2.

https://hg.mozilla.org/releases/mozilla-release/rev/8d45b6fe18e95aa6a0c73906d648c9c2ed71652d
https://hg.mozilla.org/releases/mozilla-esr68/rev/8d45b6fe18e95aa6a0c73906d648c9c2ed71652d

https://hg.mozilla.org/mozilla-central/rev/2ad059cc9e78

https://hg.mozilla.org/mozilla-central/rev/67c10b4049fa

Thanks Mozilla team for the fix ❤😊

Hello,
Using the steps from comment 18 with Firefox 69.0a1 (20190610214846) on Windows 10x64 the console message is 'WHAT?!?'.

Using the above steps with Firefox 68.0esr (20190705221915) and Firefox 68.0 (20190705220548) on Windows 10x64 I get the expected results (different from 'WHAT?!?') when running a.html. Setting the pref privacy.file_unique_origin to false I get 'WHAT?!?' in browser console as expected.

Thank you!

Hello,
Verified as fixed following the steps provided on comment 4.
Build:

• 68.0 build 3;

Devices:

• Huawei P20 Lite (Android 9);
• Xiaomi Mi 8 Lite (Android 9);
• Windows 10/x64.

The issue was verified on Firefox 69.0a1 (20190707211726) on Windows 10x64. Modifying the flags. Thank you!

Assigning CVE-2019-11730 to this.

Is there a bounty for a CVE? If not, it's all right, I am just asking. Thank you!

Best regards, Luigi

(In reply to Luigi Gubello from comment #31)

Is there a bounty for a CVE? If not, it's all right, I am just asking. Thank you!

See https://www.mozilla.org/en-US/security/client-bug-bounty/ for details on our bug bounty program, in particular the part under "Claiming a Bug Bounty" that talks about emailing security@mozilla.org .

Re: the security bug bounty for this bug. The underlying file:/// behavior was long known (since we tightened it from "all file: is same origin", in fact: it was a compromise from the start) and the various ways to abuse it. That's why we've wanted to get stricter since bug 803143. The bounty was not awarded for this known behavior, but rather specifically for the demonstration of how this interacts badly with a popular Android app and put at risk a large number of Firefox for Android users who also use WhatsApp.

Adding :tmaity to CC list as part of RCA Phase II review.

Requesting a root cause entered for blockers in recent releases in security groups. See :tmaity for details.