1908496 - (CVE-2024-8383) Locally installed application can register “news” and “snews” protocols and get opened by default

Status: VERIFIED FIXED

(Firefox :: File Handling, defect)

Description

Attachment: poc.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36

Steps to reproduce:

Reproduce

1、git clone https://github.com/koocola/test_app.git
2、Browse poc.html in firefox.
3、open the click_me button or wait 30s then you will see calculator open

Details

• reference to => CVE-2023-7012

• https://issues.chromium.org/issues/40061509

• This behaves the same as Chrome before the patch and could have a big impact on macOS.

• I'm reporting this because there hasn't been a patch for Firefox in two years.

mailto, news, snews are three external URL schemes in firefox that are handled by default without asking the user for permission.
On Windows or Linux, this is fine and can be considered a feature. However, this can have serious security implications on macos.

In macos, most user don’t have an application to handle news and snews url scheme. And if an application was download from network. Macos system will automatically register the application’s url scheme from its info.plist. Turns out if a malicious application with news and snews url scheme mentioned in there info.plist. Then chrome can use snews://xxx or news://xxx to open it. Lead to arbitrary codeexecution.

However, macos has there own security mechanism called gatekeeper to detect user open the application from network directly. If user download an application from network directly. Then the file will be set a flag com.apple.quarantine. The first open of an application with this flag will ask user whether they really want to open this application which is from network.

1、Using git or curl(eg..).

If an application is downloaded from git or curl. It will not set the flag “com.apple.quarantine”. It means the application can be opened without any warning message. So bypass the gatekeeper.

So there has a attack situation.

User visit attacker’s website. Attacker could guide user to use git to clone a malicious github or gitlab repo which include a malicious application has “news” and “snews” url scheme mentioned in there info.plist. Once git clone success. the “news” and “snews” url scheme will be registered to mac. Then the website in chrome can use “news” or “snews” url scheme to open the malicious app.

**In this attack situation. The only thing user should do is to git clone a repo. User will not realize this operation has any security impact. And then rce and sbx escape will be achieved.**

2、 With a gatekeeper bypass bug in mac.

Although user may upgrade chrome to the newest version. there operation system may not upgrade to the newest. And the version of user’s operation system information will be sent to attacker by the first get requests user requests the website. If a user’s operation system is lower then 15.1( user don’t upgrade there system after july, 2022). User can use cve-2022-32910(See https://www.jamf.com/blog/jamf-threat-labs-macos-archive-utility-vulnerability/) to bypass gatekeeper.

So there has a attack situation.

A user don’t upgrade there operation system from july,2022. A user visit attacker's website. Attacker’s website automatically download a zip file. User curiously click the zip file then macos will automatically unzip it. Then a malicious application will be released to user’s computer and “news”,snews url scheme is registered. After that , the website can open this malicious application without user's permission with the url scheme being registered.

Comment 1

[D4ni31 [:d4ni31]]

The PoC for this has been released and difficult conditions are required to utilize it. However, if there is an additional gatekeeper bypass vulnerability in macOS, it is very easy to exploit.

Now, two years after the patch was published in Chrome, it could potentially be exploited In The Wild.

Comment 2

[Andrew McCreight [:mccr8]]

As far as I can tell, it looks like the relevant settings in Firefox are here. We also have "nntp" in addition to "news" and "snews" which might be a problem.

Comment 3

[Andrew McCreight [:mccr8]]

I've tried to update the summary to be more specific. I might be off here.

Comment 4

[:Gijs (he/him)]

So this is git being careless, macOS being careless, and we're left holding the bag? Great.

I'm a bit confused about the state of macOS - the Chrome ticket suggests that modern versions of macOS are still vulnerable. Is that the case or not? (It also alleges that the website can determine the macOS version; I don't believe that is trivially true in Firefox as we do not support client hints.)

Anyway, given Chrome has removed support for opening news/snews without prompting, we probably could, too.

Comment 5

[Andrew McCreight [:mccr8]]

The initial Chrome report was filed in 2022. It was hidden until about a month ago, and then it sounds like they unhid it because Apple fixed the Gatekeeper bypass.

Comment 6

[Andrew McCreight [:mccr8]]

Discussion of the Gatekeeper bypass fix is here, near the end.

Comment 7

[Daniel Veditz [:dveditz]]

news and snews are no longer relevant, as they once were (especially to firefox development) twenty years ago when I apparently added those settings. Mailto we still need to keep without warning, even though hypothetical gatekeeper bugs would make that just as exploitable. People will be annoyed by the warning and turn it off, and most OSs already ship with a default mailto handler.

This "exploit" depends on people installing software on their machine and letting it register itself as a handler with the OS, which is already in "you lose" territory.

Comment 8

[D4ni31 [:d4ni31]]

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

This "exploit" depends on people installing software on their machine and letting it register itself as a handler with the OS, which is already in "you lose" territory.

There is something we need to check in this part. As can be seen in the report, if we can download a malicious application through git clone or curl, not only is it not affected by gatekeeper, but macOS automatically registers the handler in info.plist even if the malicious application is not run.

This means that the user does not need to register a separate handler.

I tested on firefox 128.0.0 and macOS New Beta.

Comment 9

[D4ni31 [:d4ni31]]

Attachment: repro.mov

Comment 10

[D4ni31 [:d4ni31]]

(In reply to D4ni31 from comment #0)

In macos, most user don’t have an application to handle news and snews url scheme. And if an application was download from network. Macos system will automatically register the application’s url scheme from its info.plist. Turns out if a malicious application with news and snews url scheme mentioned in there info.plist. Then chrome can use snews://xxx or news://xxx to open it. Lead to arbitrary codeexecution.

There is no need for users to register url handlers arbitrarily. Taking these things into consideration, could you please change it to sec-moderate, the same as chrome?

Comment 11

[:Gijs (he/him)]

Attachment: Bug 1908496 - adjust defaults for news/snews/nntp protocols, r?dveditz

Comment 12

[Andrew McCreight [:mccr8]]

(In reply to D4ni31 from comment #10)

There is no need for users to register url handlers arbitrarily. Taking these things into consideration, could you please change it to sec-moderate, the same as chrome?

Looking at comments 17 through 19 in the Chromium issue 40061509, it sounds like they marked it Sev-Low:

I think I can accept this being Sev-Low, based on "Low severity vulnerabilities are usually bugs that would normally be a higher severity, but which have extreme mitigating factors or highly limited scope." If you're comfortable, I'll make that change and drop this to a P2.

+1 to Sev-Low Pri-2

Adjusting priority and severity per the last couple of comments, thanks.

Comment 30 suggests changing it to Medium severity, but I'm not sure anything happened with that, because later comment 49 says:

Chrome was a very small part of this chain, and the impact of the Chrome url scheme has been thoroughly assessed here to be of very low severity and impact on its own.

Comment 13

[D4ni31 [:d4ni31]]

This was published as moderate in the September '23 patch, and comment 49 is a response to a request by a researcher who reported to Chrome to reevaluate the VRP reward. (ref comment 46)

• https://chromereleases.googleblog.com/2023/09/stable-channel-update-for-desktop_12.html

Comment 14

[Andrew McCreight [:mccr8]]

Ah, thanks for the reference. Much easier to just read that than try to decipher the bug tracker comments.

Comment 15

[D4ni31 [:d4ni31]]

Hello!

Any update for this report?
Additionally, when this is published publicly, can I use the following credits?
CREDIT : D7

Comment 16

[Andrew McCreight [:mccr8]]

It looks like this is waiting on review from dveditz. I'll ask him to take a look.

Comment 17

[D4ni31 [:d4ni31]]

Thanks :)

Comment 18

[Daniel Veditz [:dveditz]]

There is no need for users to register url handlers arbitrarily.

I didn't say there was: I said that people had to install bad software on their machine; registering a protocol handler is the least it can do at that point.

It's a fair point that due to a Gatekeeper bug (or two), in the initial chromium bug users only had to download an executable or let Chrome automatically unpack an archive containing an executable, two operations that users would not normally consider dangerous and might not even be aware there were executables present (e.g. the case of cloning a source code repo).

(In reply to Andrew McCreight [:mccr8] from comment #6)

Discussion of the Gatekeeper bypass fix is here, near the end.

Were there two different Gatekeeper bugs? That was only one of them, and in April it was only fixed in the Beta version. And then "fixed" in June. But D4ni31 said they tested it on the Beta in July. But these would be security fixes -- Apple wouldn't reserve them only for the not-yet-released versions of it's OS would they?

In any case, the Gatekeeper bug does not appear to be fixed on Sonoma 14.6. OK, I can agree with Amy in https://issues.chromium.org/issues/40061509#comment30 and go for a sec-moderate

Interesting to me that I did already have a news/snews handler installed—Thunderbird—that previously definitely got those requests, and after the git clone from the STR, the downloaded app got the requests.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4c1e4e121b5d
adjust defaults for news/snews/nntp protocols, r=dveditz

Comment 20

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

https://hg.mozilla.org/mozilla-central/rev/4c1e4e121b5d

Comment 21

[D4ni31 [:d4ni31]]

Hello!

This is a REMIND.
when this is published publicly, can I use the following credits?

CREDIT : D7

Comment 22

[:Gijs (he/him)]

Attachment: Bug 1908496 - adjust defaults for news/snews/nntp protocols, r?dveditz

Original Revision: https://phabricator.services.mozilla.com/D216938

Comment 23

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: Potential for abuse through security vulnerabilities in macOS
• Code covered by automated testing: no
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Ensure you have an app set as a default news/nntp protocol handler, then click a link using that protocol and verify there's a prompt shown to approve opening the link
• Risk associated with taking this patch: Very low
• Explanation of risk level: Just some pref flips
• String changes made/needed: No
• Is Android affected?: no

Comment 24

[Pulsebot]

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

Comment 25

[Bogdan Maris, Desktop Test Engineering]

Reproduced the issue from comment 0 using an old Nightly build from 2024-07-17 with the app directly opening without a prompt.
Verified that using latest Nightly build 131.0a1 and Firefox 130.0b5 on macOS 13.6 and the steps from comment 0 the prompt is now shown after 30s or if clicking the button from the poc file, also accessing some news: links will also show the same prompt and if selecting an app like (Thunderbird, Usenapp, Newslaser etc.)

Comment 26

[Ryan VanderMeulen (PTO, back 6-April)]

Please nominate this for ESR128 and ESR115 uplift also. It grafts cleanly to both.

Comment 27

[:Gijs (he/him)]

Attachment: Bug 1908496 - adjust defaults for news/snews/nntp protocols, r?dveditz

Original Revision: https://phabricator.services.mozilla.com/D216938

Comment 28

[Phabricator Automation]

esr115 Uplift Approval Request

• User impact if declined: Potential for abuse through security vulnerabilities in macOS
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: See comment 23
• Risk associated with taking this patch: Very low
• Explanation of risk level: just pref flips
• String changes made/needed: No
• Is Android affected?: no

Comment 29

[:Gijs (he/him)]

Attachment: Bug 1908496 - adjust defaults for news/snews/nntp protocols, r?dveditz

Original Revision: https://phabricator.services.mozilla.com/D216938

Comment 30

[:Gijs (he/him)]

and https://phabricator.services.mozilla.com/D219572 for esr128 (somehow not public yet)

Comment 31

[Phabricator Automation]

esr128 Uplift Approval Request

• User impact if declined: Potential for abuse through security vulnerabilities in macOS
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: See comment 23
• Risk associated with taking this patch: Very low
• Explanation of risk level: just pref flips
• String changes made/needed: No
• Is Android affected?: no

Comment 32

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/78f71c49cfd2

Comment 33

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/aa261d60ddd1

Comment 34

[Bogdan Maris, Desktop Test Engineering]

(In reply to Bogdan Maris, Desktop Test Engineering from comment #25)

Reproduced the issue from comment 0 using an old Nightly build from 2024-07-17 with the app directly opening without a prompt.
Verified that using latest Nightly build 131.0a1 and Firefox 130.0b5 on macOS 13.6 and the steps from comment 0 the prompt is now shown after 30s or if clicking the button from the poc file, also accessing some news: links will also show the same prompt and if selecting an app like (Thunderbird, Usenapp, Newslaser etc.)

Also verified as fixed using Firefox 115.15.0esr and Firefox 128.2.0esr.

Comment 35

[Daniel Veditz [:dveditz]]

Attachment: advisory.txt