1733775 - Browser API can lead to 'one click' Remote Code Execution

Status: RESOLVED FIXED

(WebExtensions :: General, defect)

Description

[parkminchan]

Attachment: inetloc.zip

[VULNERABILITY DETAILS]
macOS has vulnerability due to insufficient input validation by the Finder (com.apple.generic-internet-location)

An attacker could exploit this vulnerability by providing crafted inetloc file.

This vulnerability bypasses Apple's File Quarantine and Gatekeeper technologies, and allows arbitrary code execution.

By the way, Using Firefox Extension API (browser.downloads.download / browser.downloads.open) can lead to 'one-click' Remote Code Execution via .inetloc file.

[VERSION]
Firefox Version: 92.0.1 (64bit)
Operating System: macOS Big Sur, version 11.5.1(20G80)

[REPRODUCTION CASE]

1. Install the attacked extension
2. Just click cute cat image in the popup
3. "bin/sh" executed

Comment 1

[:Gijs (he/him)]

As I expressed in bug 1731779, I think this is an apple bug that they need to fix; inetloc files shouldn't be able to refer to file URLs, which apple has previously addressed, but they've neglected to do case-insensitive comparisons which means linking to FiLe: still produces problems (cf. this press article: https://www.tomsguide.com/uk/news/macos-finder-inetloc-flaw )

(In reply to parkminchan from comment #0)

3. "bin/sh" executed

As far as I can tell it isn't possible to pass any parameters to sh from an inetloc file, so I think it's likely to be tricky to make this a realistic "one click" RCE, as you'd need to download some other executable and make sure that that doesn't itself produce warnings ("this application was downloaded from the internet" etc. etc.) which is the usual defence mechanism for problems like this. If the other file doesn't produce those warnings, you could probably just run such a file directly without the indirection through the inetloc file, right?

Comment 2

[parkminchan]

Did someone report the same bug as me through bug1731779?

Anyway, it is true that configuring a full chain with inetloc as a gadget is vulnerable to arbitrary command execution.

Fundamentally, I think it is right for Firefox to prepare for the inetloc extension.

I am the person who reported the finder rce, and I have recently been able to encounter attacks such as Full Chain RCE of the Opera browser using the finder rce.

CISCO's TALOS team also recognized the risk of finder rce and added it to snort's ruleset.

The same goes for trend micro, and I think this is a clear vulnerability.

I think appropriate security processing should be performed, such as Bug 1596668 (CVE-2020-6797).

Comment 3

[parkminchan]

Inetloc is an extension originally derived to address only https:// or ftp://. However, by bypassing the limitation of the file schema, I can perform exactly the same function as fileloc.

Therefore, considering the problems mentioned in Bug 1596668, I think it is wise to be patched in the same way.

If inetloc is not fundamentally handled, there is plenty of room for future attacks in some way.

Attacks using inetloc can bypass Apple's File Quarantine and Gatekeeper, allowing users to run any application or binary downloaded from the Internet through inetloc files without any security notifications.

If you control the API by chaining with UXSS, you can also create a full-chain RCE.

Comment 4

[:Gijs (he/him)]

(In reply to parkminchan from comment #2)

Did someone report the same bug as me through bug1731779?

They didn't consider the use of webextensions, which is why I haven't duped the bug over.

CISCO's TALOS team also recognized the risk of finder rce and added it to snort's ruleset.

The same goes for trend micro, and I think this is a clear vulnerability.

What are these rules based on? I'm guessing that both of these products have a possibility to make a determination based on the contents of the inetloc file. This isn't realistically possible for Firefox, so we'd have to block/warn for all inetloc files. That seems excessive, as they're basically glorified bookmarks.

On a pretty regular basis, people find ways of exploiting desktop software with malicious files (pdfs, word documents, audio/video formats, etc.). If we started blocking those filetypes wholesale every time this happened, people would be clicking through warnings for every file they download, which is clearly counterproductive. Instead we rely on google safebrowsing to detect malicious files - but AIUI we can't add new filetypes to that unilaterally in a way that would be effective for this issue (ie we could get inetloc files users download sent to safebrowsing for checks but that won't make a practical difference right now, AIUI). Dimi, can you confirm that my understanding is correct?

I think appropriate security processing should be performed, such as Bug 1596668 (CVE-2020-6797).

This warned for all fileloc files because the usecase for a web-obtained pointer-to-a-file is nearly non-existent - a website shouldn't be in the business of pointing to files on your local system. I don't think the same is going to be true for inetloc, given that they would ordinarily point at websites or other publicly accessible places that aren't on the same machine. The fact that there is a malicious usecase for them doesn't mean they have no benign purpose, and in that sense they are different to fileloc - there'd be quite a bit of baby thrown out with the bathwater, as it were.

There is an additional problem, which is that if we did warn for these files, the standard warning is unlikely to help users. The standard warning talks about executable files, but if you downloaded, say, google.inetloc from the internet and it was malicious, a warning that google.inetloc (or win10thousanddollars.inetloc or...) may harm your computer is unlikely to seem credible to a user, so they'll probably just accept the dialog anyway. :-\

Attacks using inetloc can bypass Apple's File Quarantine and Gatekeeper, allowing users to run any application or binary downloaded from the Internet through inetloc files without any security notifications.

Can you explain what you mean here, and/or provide steps to reproduce? Are you saying that "executing" the inetloc file executes applications or binaries that are downloaded without warning, when executing those files directly does show a warning? (This would be a further vulnerability that I think would be worth reporting to Apple, but it may also mean we need to be more aggressive in our fix despite the downsides of doing that...)

Comment 5

[Dimi Lee [:dimi]]

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

Instead we rely on google safebrowsing to detect malicious files - but AIUI we can't add new filetypes to that unilaterally in a way that would be effective for this issue (ie we could get inetloc files users download sent to safebrowsing for checks but that won't make a practical difference right now, AIUI). Dimi, can you confirm that my understanding is correct?

You are right; as far as I know, inetloc file is not included in the list of extensions that should be sent to SafeBrowsing in Chromium at this point. So sending inetloc files to SafeBrowsing won't help this issue now. I'm not sure if they have the plan to add inetloc, but if they do, we can include the file type to our download protection checklist.

Comment 6

[:Gijs (he/him)]

I think this is now fixed (ie will show the same warnings as fileloc) through the patch on bug 1731779 on nightly (95), beta (94) and latest treeherder esr91 build (ie from https://treeherder.mozilla.org/jobs?repo=mozilla-esr91&revision=7d4e4d060f57552b3d49edc5a9691a42c38fd865 , not shipped to the esr update channel yet).

Reporter, are you in a position to verfy this?

Comment 7

[Anca Soncutean, Desktop QA]

I can’t reproduce this issue on my end (or I am missing something). Parkminchan could you help us confirm the fix on your side on the latest Firefox builds?