1773717 - (CVE-2022-34478) Block ms-msdt and search-ms protocols to prevent security issues

Status: VERIFIED FIXED

(Firefox :: File Handling, defect)

Description

[:Gijs (he/him)]

See https://www.bleepingcomputer.com/news/security/new-windows-search-zero-day-added-to-microsoft-protocol-nightmare/amp/ .

Comment 1

[Daniel Veditz [:dveditz]]

It appears we should block the search: protocol as well. In theory some other application could register for that (is that possibly worse?) but it looks like by default it's the same service as search-ms:
https://docs.microsoft.com/en-us/windows/win32/shell/search-protocol

Comment 2

[Daniel Veditz [:dveditz]]

Attachment: Telemetry data for beta 95

Here are the telemetry counts from beta 95. This was an opt-out telemetry probe so we might be able to get better data from Release elsewhere, but at least here I didn't see any use of the "SEARCH" bucket (combines search: and search-ms:). There was a bunch of "MICROSOFT-APP" though. Unlikely anyone actually used ms-msdt: but if they did it would be in that ms-* bucket.

Comment 3

[Daniel Veditz [:dveditz]]

Note: the probe was added by the privacy/anti-tracking team to measure potential breakage for different mitigations they were considering (see bug 1672344). The counts are broken into 6 different frame scenarios so you need to add them together (unless we ended up blocking some scenarios based on the telemetry)

Comment 4

[:Gijs (he/him)]

Attachment: Bug 1773717, r?dveditz

Comment 5

[Andrew McCreight [:mccr8]]

What rating should this have? Should it be sec-critical because it is being exploited in the wild (though not as far as we know for Firefox...)? Or something lower? I'm not entirely sure how bad it is. Thanks.

Comment 6

[:Gijs (he/him)]

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

What rating should this have? Should it be sec-critical because it is being exploited in the wild (though not as far as we know for Firefox...)? Or something lower? I'm not entirely sure how bad it is. Thanks.

Even without this patch we will still show a prompt to ask if a site should be allowed to access the protocol, plus it's not really our bug, so I don't think it's sec-crit. bug 1721107 was sec-moderate, so I guess we can do the same thing here? Though equally the IE bug that that exploited was not as bad as this one.

Comment 7

[:Gijs (he/him)]

Comment on attachment 9281435 [details]
Bug 1773717, r?dveditz

Beta/Release Uplift Approval Request

• User impact if declined: Security impact because of MS bugs
• 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: Check that these protocols (ms-msdt, search and search-ms) are blocked on Windows machines.
• 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 pref additions. We could revert with normandy if we inadvertently break important usecases by blocking these protocols (which engineering does not think likely right now).
• String changes made/needed: None
• Is Android affected?: No

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Security vector
• User impact if declined: See above
• Fix Landed on Version: 103
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): See above

Comment 8

[Daniel Veditz [:dveditz]]

[Tracking Requested - why for this release]:
We should land this on ESR when we ship this in Firefox.

Firefox is not currently being abused with this vector (as far as we know), mostly because the additional steps compared to the MS Word vector will require more social engineering. But as articles have spread the idea of the attack to less discerning scammers we should expect that people are going to eventually start spamming people with this trick. Getting this into 102 would be a way to stay ahead of it. The patch is trivially safe, and any enterprises who use this protocol can use policy settings to change it back. Both the external-protocol preference mechanism and the group controls for these prefs are already in use for other schemes and well-tested.

Comment 9

[Pascal Chevrel:pascalc]

Comment on attachment 9281435 [details]
Bug 1773717, r?dveditz

Driver for a RC2, approved for 102, 102esr, 91esr.

Comment 10

[Pascal Chevrel:pascalc]

https://hg.mozilla.org/releases/mozilla-release/rev/b6b2b8930fdf

Comment 11

[Pascal Chevrel:pascalc]

https://hg.mozilla.org/releases/mozilla-esr102/rev/647b9d921d3f

Comment 12

[Pascal Chevrel:pascalc]

https://hg.mozilla.org/releases/mozilla-esr91/rev/7ac9b20c412b

Comment 13

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

r=dveditz
https://hg.mozilla.org/integration/autoland/rev/d1ddb1ce916bfc3478e43e7f55f3d103322b0eb5
https://hg.mozilla.org/mozilla-central/rev/d1ddb1ce916b

Comment 14

[Adrian Florinescu [:aflorinescu]]

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

• If yes, steps to reproduce: Check that these protocols (ms-msdt, search and search-ms) are blocked on Windows machines.

Can you please elaborate a bit more on the above?

Comment 15

[:Gijs (he/him)]

(In reply to Adrian Florinescu [:aflorinescu] from comment #14)

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

• If yes, steps to reproduce: Check that these protocols (ms-msdt, search and search-ms) are blocked on Windows machines.

Can you please elaborate a bit more on the above?

Try loading any of these from the address bar:

ms-msdt:foo
search:foo
search-ms:foo

on a clean profile and check if you get a prompt asking to confirm an application (pre-patch), or if it just does nothing (post-patch).

Comment 16

[Adrian Florinescu [:aflorinescu]]

Thank you @Gijs, resulting STR:

1. With Nightly <= 06.22, in address bar, input:
   a. ms-msdt:foo ->> opens confirmation dialog or win searches
   b. search:foo ->> opens confirmation dialog or win searches
   c. search-ms:foo ->> opens confirmation dialog or win searches
2. Upgrade to the latest >= 06/23
   a. ms-msdt:foo ->> nothing happens
   b. search:foo ->> nothing happens
   c. search-ms:foo ->> nothing happens
3. Go about:config and enable the following:
   a. pref("network.protocol-handler.external.ms-msdt", true);
   b. pref("network.protocol-handler.external.search", true);
   c. pref("network.protocol-handler.external.search-ms", true);
4. In address bar input:
   a. ms-msdt:foo ->> opens confirmation dialog or win searches
   b. search:foo ->> opens confirmation dialog or win searches
   c. search-ms:foo ->> opens confirmation dialog or win searches

Verification as follows:

I. - Nightly 103 06.23 with Windows 10 version 21h2 19044.1766 - all good
II. - Nightly 103 06.23 with Windows 11 22000.739 - all good
III. - Nightly 103 06.23 with Windows 8 (6.2 9200) - ms-msdt:foo still active post patch and prefs default, opening a windows search (search and search-ms disabled as expected)
IV. - Nightly 103 06.23 with Windows 7 Pro N 7601 - ms-msdt:foo still active post patch and prefs default, opening a windows search (search and search-ms disabled as expected)

Ping @Gijs back for results III. and IV., should we spin a follow-up?

Comment 17

[Tom Ritter [:tjr]]

Attachment: advisory.txt

Comment 18

[Adrian Florinescu [:aflorinescu]]

(In reply to Adrian Florinescu [:aflorinescu] from comment #16)

III. - Nightly 103 06.23 with Windows 8 (6.2 9200) - ms-msdt:foo still active post patch and prefs default, opening a windows search (search and search-ms disabled as expected)
IV. - Nightly 103 06.23 with Windows 7 Pro N 7601 - ms-msdt:foo still active post patch and prefs default, opening a windows search (search and search-ms disabled as expected)

The above was a bit of confusion during testing, the ms-msdt:foo would open a google search, not a windows search dialog, so ms-msdt:foo is not active at all on w7/w8. Removing NI and completed 102RC2 and 102ESR RC2 verification as follows:

I. - 102.0esr 2022-06-23 & 102.0 2022-06-23 on Windows 10 21H1 19043.1706
II. - 102.0esr 2022-06-23 & 102.0 2022-06-23 on Windows 11 22000.739 - all good
III. - 102.0esr 2022-06-23 & 102.0 2022-06-23 with Windows 8.1 (version 6.3 9600) - ms-msdt:foo not available for windows 8.1, opening a windows search (search and search-ms disabled as expected)
IV. - 102.0esr 2022-06-23 & 102.0 2022-06-23 with Windows 7 Pro N 7601 - ms-msdt:foo not available for windows 8.1 (search and search-ms disabled as expected)

Comment 19

[Adrian Florinescu [:aflorinescu]]

Lastly, verification with 91.11.0esr 2022-06-23 on the same OS'es as in comment 18 completed.

Comment 20

[Daniel Veditz [:dveditz]]

The above was a bit of confusion during testing, the ms-msdt:foo would open a google search, not a windows search dialog, so ms-msdt:foo is not active at all on w7/w8.

That is correct. ms-msdt: was introduced in Windows 10. If the awesomebar starts with scheme-looking text but it's not a protocol built-in to Firefox and not known by the OS, then we treat it as a search term rather than a URL.