1721107 - (CVE-2021-38492) Use of mk:@MSITStore: URI from Firefox can run JavaScript in IE with res: URI

Status: VERIFIED FIXED

(Core :: Networking, defect)

Description

[James Lee]

We are able to reproduce bug id 1549833 and 1552627 (https://bugzilla.mozilla.org/show_bug.cgi?id=1552627) using mk:@MSITStore: URI.

1. We can run Internet Explorer from chrome, which allows us to run JavaScript at renderer process privilege (Low or AppContainer IL, depending on user's IE11 EPM Sandbox setting).

https://pwning.click/ffscheme.php

2. Elevation of Privilege- from AppContainer or Low Integrity Level to Medium IL JavaScript execution

https://pwning.click/ffscheme2.php

3. Other bugs- Security Feature bypass such as running VBScript at Medium Integrity Level, which should be not possible from Internet Zone IE11 : this is possible because IE let attackers reading OS username (Test on https://pwning.click/osuname.php) which allows running downloaded file from the Website after the browser crashes and reopens (the downloaded .html file will open automatically after the crash, which runs Medium IL VBScript).

Reading/running local files and more

https://pwning.click/ffscheme3.php

Fix- Filter mk:@MSITStore: URI

Comment 1

[Daniel Veditz [:dveditz]]

This is really a MS bug at heart -- when we've talked to them about this they have insisted that if there's a published URL handler then it's intended to be safe. But IE is out of support so it would be good to be able to prevent launching it.

Comment 2

[Daniel Veditz [:dveditz]]

Chrome originally wontfixed this a while back in crbug 1009268 but then this week came around and fixed it in crbug 1223290 with this patch: https://chromium.googlesource.com/chromium/src/+/5576e533a0da56df93242e2b361a306df2b6c1ec

Reviewed by Eric Lawrence who had earlier said https://bugs.chromium.org/p/chromium/issues/detail?id=1009268#c13, so I trust that we need to also block it.

Comment 3

[:Gijs (he/him)]

Attachment: Bug 1721107 - block mk protocol, r?dveditz

Comment 4

[:Gijs (he/him)]

Comment on attachment 9237198 [details]
Bug 1721107 - block mk protocol, r?dveditz

Beta/Release Uplift Approval Request

• User impact if declined: Security risk
• 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: Try links from comment 0; IE should not open and no dialog should pop up offering to do so.
• List of other uplifts needed: n/a
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Simple pref change
• String changes made/needed: None

Comment 5

[:Gijs (he/him)]

Comment on attachment 9237198 [details]
Bug 1721107 - block mk protocol, r?dveditz

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: See beta approval request for details
• User impact if declined:
• Fix Landed on Version: 93
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky):
• String or UUID changes made by this patch:

Comment 6

[:Gijs (he/him)]

Because this is effectively a trivial pref set we can push something out with Normandy to release, if desired. Dan, I'm out until Tuesday the 31st, pinging you with this idea in case you think we need to do that and get a fix out before the 92 release (I'm optimistically assuming this will get beta approval).

Comment 7

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

block mk protocol, r=dveditz
https://hg.mozilla.org/integration/autoland/rev/d7bdccdef9778c5ab082840790037104a7d81551
https://hg.mozilla.org/mozilla-central/rev/d7bdccdef977

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Is there any reason we wouldn't want this on ESR78 also?

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9237198 [details]
Bug 1721107 - block mk protocol, r?dveditz

Approved for 92.0b7 and 91.1esr. Will approve for 78.14esr pending confirmation.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/7ddc4bfff6d7
https://hg.mozilla.org/releases/mozilla-esr91/rev/452e0a21940d

Comment 11

[Bogdan Maris, Desktop Test Engineering]

Reproduced the issue using affected build (91.0 RC), verified that the links from comment 0 IE does not open and no dialog popes up when loading them on latest Beta 92, Nightly 93 and ESR 91 builds (Windows 10 and Windows 7). Leaving qe-verify+ for 78.14esr pending confirmation.

Comment 12

[Daniel Veditz [:dveditz]]

Because this is effectively a trivial pref set we can push something out with Normandy to release, if desired.

Moot point now since this already landed on branches, but we didn't need to worry about jumping through Normandy hoops for this. I would've waited a little longer before landing on branches but I guess RC1 builds are coming up fast anyway.

No reason not to land on ESR-78 too since we still support it for another couple of months. People will ask if we don't.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9237198 [details]
Bug 1721107 - block mk protocol, r?dveditz

Approved for 78.14esr.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/479129f77f54

Comment 15

[Bogdan Maris, Desktop Test Engineering]

(In reply to Bogdan Maris [:bogdan_maris], Release Desktop QA from comment #11)

Reproduced the issue using affected build (91.0 RC), verified that the links from comment 0 IE does not open and no dialog popes up when loading them on latest Beta 92, Nightly 93 and ESR 91 builds (Windows 10 and Windows 7). Leaving qe-verify+ for 78.14esr pending confirmation.

Also verified fixed using latest 78esr build from treeherder on Windows 10 and 7.

Comment 16

[Frederik Braun [:freddy]]

Attachment: advisory.txt