1596668 - (CVE-2020-6797) Firefox for macOS: extensions with downloads.open permission can execute code on the device using .fileloc files

Status: VERIFIED FIXED

(Firefox :: File Handling, defect, P1)

Description

[Vladimir Metnew]

Attachment: firefox-extension-fileloc.zip

FF Version: 70.0.1
macOS: 10.15.1 (19B88)

1. .fileloc files behave on macOS similarly to .url files on Windows - as shortcuts that can execute local apps.
2. A malicious extension with downloads/downloads.open permissions can download a .fileloc file + execute it to launch arbitrary local apps.
3. It looks like a non-secure feature of macOS(that I'm going to report), so it's not clear what'd be your opinion. I guess you'd like to add this file to your file handling mechanism as well.

PoC opens Calculator.app on Catalina.

Comment 1

[:Gijs (he/him)]

Shane, under what circumstances are webextensions supposed to be able to execute arbitrary local executables? I assume that addons with native messaging can already do this, and maybe others?

Comment 2

[:Gijs (he/him)]

In fact, let's move this to webextensions for now. I imagine this issue doesn't just affect fileloc files, and/or if it does, that whatever lists other "dangerous" things should be what's listing this, not core Firefox code. We can always move it back if there's shared code being used that I'm not aware of.

Comment 3

[Shane Caraveo (:mixedpuppy)]

I'm unable to reproduce this on osx 10.14 with release or nightly. We need to find someone with 10.15 to verify.

After fixing the app path in the popup js file, when I use the extension to download then click the "run" button, the file is opened in textedit.

I am able to use the downloaded x.fileloc from Finder and the command line to open an application.

The downloads.open API merely calls launch on the download, so if this were to work, it should work without an extension involved at all. Just download a fileloc file somewhere and open it from the downloads panel.

Vladimir, does opening the downloaded file from the downloads panel also work for opening the app?

[1] https://searchfox.org/mozilla-central/rev/131338e5017bc0283d86fb73844407b9a2155c98/toolkit/components/extensions/parent/ext-downloads.js#951
[2] https://searchfox.org/mozilla-central/rev/131338e5017bc0283d86fb73844407b9a2155c98/toolkit/components/downloads/DownloadCore.jsm#734
[3] https://searchfox.org/mozilla-central/rev/131338e5017bc0283d86fb73844407b9a2155c98/toolkit/components/downloads/DownloadIntegration.jsm#721

Comment 4

[Shane Caraveo (:mixedpuppy)]

Alexandru, could you verify this bug?

Comment 5

[Shane Caraveo (:mixedpuppy)]

(In reply to Shane Caraveo (:mixedpuppy) from comment #3)

Just download a fileloc file somewhere and open it from the downloads panel.

As a note, doing this on 10.14 resulted in the same behavior, from the downloads panel it opened the file in textedit, but I could use the downloaded file via Finder to open the app.

Comment 6

[Vladimir Metnew]

Vladimir, does opening the downloaded file from the downloads panel also work for opening the app?

Yeah, it's a macOS shortcut file and FF basically calls open on this file. It works for opening the app.

Default handler for .fileloc is Finder.app. Try to rebuild launchservices database, if .fileloc gets opened in TextEdit.app on your device. (might damage your macOS setup preferences) Or run macOS VM.

I setup a macOS in VM and tried to repro this again: it works. Screencast - https://drive.google.com/open?id=103he_74WHflyVLv9IxydOwGY9ewyhxJ1

Comment 7

[Shane Caraveo (:mixedpuppy)]

Given the extension api uses the underlying libraries, and that this happens as well from the downloads panel, I'm moving back in to file handling component.

Comment 8

[:Gijs (he/him)]

Talked to Marco about this. It seems we should:

1. add fileloc to the list of executable extensions (and make sure those get checked on mac, as we use the executable bit at the moment) and/or hardcode a check in nsLocalFileUnix that returns true only for this type of file
2. ensure we show the executable warning based on that, and require user interaction (that last part should already be happening)

Note that at least on my 10.14 machine, the file:///System/Applications path does not exist, which might be why the testcase doesn't work. Though the extension also fails to install for me ("extension does not contain a valid manifest").

Shane, can you confirm this seems right to you? (Also, any idea why the add-on is not installing?)

Comment 9

[Vladimir Metnew]

file:///System/Applications exists only on Catalina. (different partition, additional security measure)
You can change /System to / and it will work on Mojave as well.

(Also, any idea why the add-on is not installing?)
Probably, an issue in my code? I ctrl+c'ed the addon from FF examples on github, it may miss somethings

Comment 10

[Rob Wu [:robwu]]

(In reply to :Gijs (he/him) from comment #8)

Though the extension also fails to install for me ("extension does not contain a valid manifest").

How are you trying to install the add-on? A zip file can only be loaded directly via about:debugging if manifest.json is a top-level file in the zip file.
In the attached test case, it is inside a subdirectory. So to test the add-on, you need to extract the zip file and load the directory via about:debugging.

Comment 11

[Shane Caraveo (:mixedpuppy)]

(In reply to :Gijs (he/him) from comment #8)

Talked to Marco about this. It seems we should:

1. add fileloc to the list of executable extensions (and make sure those get checked on mac, as we use the executable bit at the moment) and/or hardcode a check in nsLocalFileUnix that returns true only for this type of file
2. ensure we show the executable warning based on that, and require user interaction (that last part should already be happening)

Note that at least on my 10.14 machine, the file:///System/Applications path does not exist, which might be why the testcase doesn't work. Though the extension also fails to install for me ("extension does not contain a valid manifest").

I changed that in my testing to point at a valid location for an application.

Shane, can you confirm this seems right to you? (Also, any idea why the add-on is not installing?)

Yeah, that seems like a good approach.

Comment 12

[:Gijs (he/him)]

I'm going to steal this to implement comment #8.

Comment 13

[Vladimir Metnew]

JFYI I’ve heard Chrome is going to deprecate downloads.open and make it an alias to downloads.show

Comment 14

[:Gijs (he/him)]

(In reply to Vladimir Metnew from comment #13)

JFYI I’ve heard Chrome is going to deprecate downloads.open and make it an alias to downloads.show

Thanks for the heads-up. Is there a public reference for this plan?

This feels like something in Shane's wheelhouse again... :-)

Comment 15

[Vladimir Metnew]

Thanks for the heads-up. Is there a public reference for this plan?

No, I submitted the same bug to Chrome, and I've just accidentally recalled they had been discussing this option to deprecate downloads.open behavior.
Completely not an official reference :)

Comment 16

[Shane Caraveo (:mixedpuppy)]

(In reply to :Gijs (he/him) from comment #14)

This feels like something in Shane's wheelhouse again... :-)

Bouncing that hot potato back to you. This can be done via the downloads panel itself, so it should be fixed (per comment 8). As well, we don't deprecate APIs overnight, and if this is being deprecated it's likely part of manifest v3.

Comment 17

[:Gijs (he/him)]

(In reply to Shane Caraveo (:mixedpuppy) from comment #16)

(In reply to :Gijs (he/him) from comment #14)

This feels like something in Shane's wheelhouse again... :-)

Bouncing that hot potato back to you. This can be done via the downloads panel itself, so it should be fixed (per comment 8). As well, we don't deprecate APIs overnight, and if this is being deprecated it's likely part of manifest v3.

To be clear, I'm still going to fix this as discussed. I was just pinging you about the deprecation stuff. Sorry for the brevity-induced lack of clarity.

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:Gijs, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 19

[:Gijs (he/him)]

After adding fileloc to the list of dangerous extensions, I get the expected prompt when using the downloads panel.

However, either way Calculator does not open (testing on Mojave) - instead, the file gets opened by textedit... I see the same thing on older Firefoxes (ie it's using textedit rather than opening the app). Unsure why I'm seeing different behaviour - OP, did you actually test on Mojave with Firefox? Perhaps something got changed wrt fileloc files on Catalina? Because when I open the file "manually" from Finder, Calculator.app appears in the dock but bounces forever. Opening calculator normally (via spotlight) works fine...

Comment 20

[:Gijs (he/him)]

Attachment: Bug 1596668, r?spohl

Comment 21

[Vladimir Metnew]

See PoC screencast I've recorded before I've submitted this bug : https://drive.google.com/open?id=103he_74WHflyVLv9IxydOwGY9ewyhxJ1
It worked fine on macOS 10.15.1 for me

Comment 22

[:Gijs (he/him)]

(In reply to Vladimir Metnew from comment #21)

See PoC screencast I've recorded before I've submitted this bug : https://drive.google.com/open?id=103he_74WHflyVLv9IxydOwGY9ewyhxJ1
It worked fine on macOS 10.15.1 for me

Sure, I'm not doubting that it works for you in 10.15. But I don't have 10.15 available right now, and you asserted in comment #9 that it works on Mojave. I'm just asking, have you actually tested Mojave? The bug is valid either way, and it's fine if you don't have access to 10.14 - but for my sanity it'd be nice to understand if I'm doing something wrong, or if there's some difference between 10.14 and 10.15 here. I tried rebuilding the launch services database, that didn't make any difference.

Comment 23

[Vladimir Metnew]

(In reply to :Gijs (he/him) from comment #22)

(In reply to Vladimir Metnew from comment #21)

See PoC screencast I've recorded before I've submitted this bug : https://drive.google.com/open?id=103he_74WHflyVLv9IxydOwGY9ewyhxJ1
It worked fine on macOS 10.15.1 for me

Sure, I'm not doubting that it works for you in 10.15. But I don't have 10.15 available right now, and you asserted in comment #9 that it works on Mojave. I'm just asking, have you actually tested Mojave? The bug is valid either way, and it's fine if you don't have access to 10.14 - but for my sanity it'd be nice to understand if I'm doing something wrong, or if there's some difference between 10.14 and 10.15 here. I tried rebuilding the launch services database, that didn't make any difference.

I observed a few cases when Calculator spins infinitely. But in this case, the binary is still mapped and executed in memory properly.
Try to change shortcut's URL to file:///usr/bin/sudo and launch via downloads.open -> Terminal.app popups and sudo outputs its help page. seems like a valid proof of the file execution

So yeah, there is no difference in OS version, because the binary is actually executed. but tbf I don't know why Calculator sometimes spins and grabs only 8K memory. Might be related to some macOS features

Comment 24

[:Gijs (he/him)]

(In reply to Vladimir Metnew from comment #23)

(In reply to :Gijs (he/him) from comment #22)

(In reply to Vladimir Metnew from comment #21)

See PoC screencast I've recorded before I've submitted this bug : https://drive.google.com/open?id=103he_74WHflyVLv9IxydOwGY9ewyhxJ1
It worked fine on macOS 10.15.1 for me

Sure, I'm not doubting that it works for you in 10.15. But I don't have 10.15 available right now, and you asserted in comment #9 that it works on Mojave. I'm just asking, have you actually tested Mojave? The bug is valid either way, and it's fine if you don't have access to 10.14 - but for my sanity it'd be nice to understand if I'm doing something wrong, or if there's some difference between 10.14 and 10.15 here. I tried rebuilding the launch services database, that didn't make any difference.

I observed a few cases when Calculator spins infinitely.

To be clear, this is what I see if I open the file from Finder. From Firefox, all I can see is it opening in textedit.

Comment 25

[Vladimir Metnew]

(In reply to :Gijs (back Jan 2; he/him) from comment #24)

(In reply to Vladimir Metnew from comment #23)

(In reply to :Gijs (he/him) from comment #22)

(In reply to Vladimir Metnew from comment #21)

See PoC screencast I've recorded before I've submitted this bug : https://drive.google.com/open?id=103he_74WHflyVLv9IxydOwGY9ewyhxJ1
It worked fine on macOS 10.15.1 for me

Sure, I'm not doubting that it works for you in 10.15. But I don't have 10.15 available right now, and you asserted in comment #9 that it works on Mojave. I'm just asking, have you actually tested Mojave? The bug is valid either way, and it's fine if you don't have access to 10.14 - but for my sanity it'd be nice to understand if I'm doing something wrong, or if there's some difference between 10.14 and 10.15 here. I tried rebuilding the launch services database, that didn't make any difference.

I observed a few cases when Calculator spins infinitely.

To be clear, this is what I see if I open the file from Finder. From Firefox, all I can see is it opening in textedit.

not sure why it happens to you now
I guess it might be an additional patch from Apple

Comment 26

[:Gijs (he/him)]

:spohl, unsure if this is review request is showing up in your queue, so just checking! :-)

Comment 27

[Stephen A Pohl [:spohl]]

(In reply to :Gijs (he/him) from comment #26)

:spohl, unsure if this is review request is showing up in your queue, so just checking! :-)

It was in my queue but I didn't get a notification and I would probably have missed it. Thank you for pinging me!

Comment 28

[:Gijs (he/him)]

https://hg.mozilla.org/integration/autoland/rev/bee05acc3ce7b56e5840e27a178262ff9a87a637

Comment 29

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

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

Comment 30

[:Gijs (he/him)]

Comment on attachment 9117703 [details]
Bug 1596668, r?spohl

Beta/Release Uplift Approval Request

• User impact if declined: Security issue
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: On a macOS 10.15 machine:

1. download the add-on attached to the bug
2. unzip it
3. open the build you're testing
4. navigate to about:debugging
5. install a temporary add-on from there
6. find the manifest.json file and pick that
7. using the add-on's toolbar button, first download and then open the file

ER:
a warning dialog about it being a dangerous file

pre patch:
No warning dialog

• List of other uplifts needed: n/a
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): trivial patch to a hardcoded list of file extensions that only affects macOS
• String changes made/needed: nope

Comment 31

[Daniel Veditz [:dveditz]]

Do .fileloc files support arguments? I was thinking like windows .lnk files, but .url files don't. Launching existing programs without arguments isn't likely too dangerous. On the other hand if you have downloads.open permission could you download two files? One an executable .app that we won't let you open, and then a .fileloc to launch it? You'd have to guess the user's download directory, though. Maybe WebExtensions can figure that out already in other ways (would have to investigate).

Comment 32

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9117703 [details]
Bug 1596668, r?spohl

Approved for 73.0b5. Should we take this on ESR too?

Comment 33

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/ebdbfe7bcbbd

Comment 34

[:Gijs (he/him)]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #32)

Comment on attachment 9117703 [details]
Bug 1596668, r?spohl

Approved for 73.0b5. Should we take this on ESR too?

We could, I think. Stephen, does that sound right to you? I don't see any issue with it (that'd suggest e.g. waiting a cycle to make sure there's no breakage) but wanted to doublecheck.

Comment 35

[Stephen A Pohl [:spohl]]

(In reply to :Gijs (he/him) from comment #34)

(In reply to Ryan VanderMeulen [:RyanVM] from comment #32)

Comment on attachment 9117703 [details]
Bug 1596668, r?spohl

Approved for 73.0b5. Should we take this on ESR too?

We could, I think. Stephen, does that sound right to you? I don't see any issue with it (that'd suggest e.g. waiting a cycle to make sure there's no breakage) but wanted to doublecheck.

This seems like a good ESR candidate due to the low risk of breakage.

Comment 36

[:Gijs (he/him)]

Comment on attachment 9117703 [details]
Bug 1596668, r?spohl

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: sec-moderate
• User impact if declined: see above
• Fix Landed on Version: 74
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): tiny patch just adding an extension to a list
• String or UUID changes made by this patch: nope

Comment 37

[Ciprian Georgiu, Desktop QA]

I've managed to reproduce the issue using the steps from comment 30, on Firefox 72.0.

The issue is not reproducing anymore on Beta 73.0b5 and Nightly 74.0a1 under macOS 10.13.6. Ni? myself as a reminder to verify this on esr68 too, once it lands.

Comment 38

[:Gijs (he/him)]

(In reply to Ciprian Georgiu [:ciprian_georgiu], Release Desktop QA from comment #37)

I've managed to reproduce the issue using the steps from comment 30, on Firefox 72.0.

The issue is not reproducing anymore on Beta 73.0b5 and Nightly 74.0a1 under macOS 10.13.6.

I'm a bit surprised; I specifically asked to check macOS 10.15. Where did you reproduce the issue with 72, and can you doublecheck you see the expected results on 10.15 as well?

Comment 39

[Ciprian Georgiu, Desktop QA]

(In reply to :Gijs (he/him) from comment #38)

I'm a bit surprised; I specifically asked to check macOS 10.15. Where did you reproduce the issue with 72, and can you doublecheck you see the expected results on 10.15 as well?

I was able to reproduce it on macOS 10.13.6 (I did not realize that this required a specific OS X version to be verified, since I've managed to see the issue on older versions).

I got the same results on macOS 10.15.1 as well, the warning dialog is correctly displayed using the same Firefox builds as per my previous comment.

Comment 40

[Vladimir Metnew]

(In reply to Daniel Veditz [:dveditz] from comment #31)

Do .fileloc files support arguments? I was thinking like windows .lnk files, but .url files don't. Launching existing programs without arguments isn't likely too dangerous. On the other hand if you have downloads.open permission could you download two files? One an executable .app that we won't let you open, and then a .fileloc to launch it? You'd have to guess the user's download directory, though. Maybe WebExtensions can figure that out already in other ways (would have to investigate).

No, .fileloc files don't support arguments :(

See my slides for a detailed impact description and additional research of macOS file quarantine issues - https://docs.google.com/presentation/d/19WeQbqc_OKnrSv1I3Z4sm-oNAf6IVzHwRyQP4i9Bv_Y/edit?usp=sharing

you have downloads.open permission
(Un)Luckily, to execute arbitrary code attacker needs:

• either to somehow plant a "launchable" file (open of which triggers code execution) with a quarantine meta attribute. This scenario is possible by sharing a file via Dropbox/OneDrive/<other_cloud_storage>. see my slides for a full list of these files and similar vulnerabilities (e.g., Keybase vuln)
• or to download + downloads.open .app + downloads.open it again + user needs to confirm GateKeeper dialog -> unrealistic scenario

I don't consider cases when File Quarantine is intentionally disabled, because in this case a single downloads.open on .terminal files leads to code execution.

Also, all utils except web browsers and sandboxed apps don't apply file quarantine at all. Files from brew/git aren't quarantined.

In theory, attacker can start some macOS-native binary which (for example) starts a local server and increase attack surface (or even exploit some OS vuln right from the web). But that's probably not a FF issue

Comment 41

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9117703 [details]
Bug 1596668, r?spohl

Approved for 68.5esr also.

Comment 42

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr68/rev/27f71a0b7aa2

Comment 43

[Ciprian Georgiu, Desktop QA]

Verified fixed as well on 68.5.0esr under macOS 10.15.1 and 10.13.6.

Comment 44

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Attachment: advisory.txt