1723281 - (CVE-2021-43542) Fast query of registered URL schemes through XMLHttpRequest for system fingerprinting

Status: RESOLVED FIXED

(Core :: DOM: Networking, defect, P2)

Description

[smolikraphael]

System fingerprinting like https://schemeflood.com/ use a slow variant, the bug enables tracking-services to fast list up all registered URL protocols. The problem on URL scheme fingerprinting is, that it will create a fingerprint for the system and not just the browser.

Tested on Windows 10 with Firefox 92 and Firefox 90.

The problem is that XMLHttpRequest will return different status codes dependent on the registration-state of the protocol or not.

Javascript code snippet:

var scheme = "spotify://dummy";

try {
var ajaxObj = new XMLHttpRequest()
ajaxObj.open("GET", scheme, false);
ajaxObj.send();
} catch (error) {
if (ajaxObj.status === 0) {
console.log("Protocol found: " + scheme);
} else { // regulary ajaxObj.status == 200
console.log("Protocol NOT found: " + scheme);
}
}

A fix would be to disallow XMLHttpRequest requests with protocols others than http, https, ...

Comment 1

[:Gijs (he/him)]

(In reply to smolikraphael from comment #0)

A fix would be to disallow XMLHttpRequest requests with protocols others than http, https, ...

This seems like the kind of thing the fetch spec has something to say about. Anne, do you know if that is the case?

Comment 2

[Anne (:annevk)]

Yeah, as per https://fetch.spec.whatwg.org/#scheme-fetch anything other than about:/blob:/data:/file:/http:/https: ought to return a network error (which would result in status 0).

And that is the case for everything that invokes fetch, including XMLHttpRequest. The only thing that can handle other schemes is HTML's navigate algorithm, which only defers to fetch for certain schemes.

When fixing this we should make sure that HTML's <img>, CSS's background-image, fetch(), etc. do not have the same problem.

Kershaw, would you have time to look into this? (In case you see this while still OOO, please ignore until you are back. 😊)

Comment 3

[smolikraphael]

I created a little example page to retrieve data from a client, for this project I found this bug. It checks the schemes dependent on the user agent to use different methods to check the schemes. (Firefox: this bug; chrome: focus loss method like https://schemeflood.com/ ; Edge a other method, that opens in the worst case each program; the last two will ask the user to start, because the bug is the single way, the user won't recognize). The found protocols will be displayed at the bottom. Here is the site. https://v2202108153726159664.quicksrv.de/

I now tested it with different systems:
Windows 10 the bug is there (tested with Firefox 90 and 92).
Android seems to list all schemes. (latest Firefox version and android 10)
Tor with Windows also won't work (I think because there are all prtotocol interactions restricted).
Ubuntu (21) and Firefox 89, the bug is also in.
Windows 8.1 and Firefox 78 and 90 the bug is also in.

This is just an update, I hope this is helpful for you.
I also have a question am I allowed to publish the bug, or is there any limitation in concerne with the bounty (if it is even relevant)?

Comment 4

[:Gijs (he/him)]

(In reply to smolikraphael from comment #3)

I also have a question am I allowed to publish the bug, or is there any limitation in concerne with the bounty (if it is even relevant)?

Passing this question to Tom explicitly...

Comment 5

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

(In reply to smolikraphael from comment #3)

I also have a question am I allowed to publish the bug, or is there any limitation in concerne with the bounty (if it is even relevant)?

From a general security policy point of view, we would appreciate the opportunity to address the issue before it is published and some notice about when it will be published if so. From a Bug Bounty point of view, if a bug is made public before the issue is fixed, we generally look at the time that passed and events that occurred between reporting and publishing, and try to judge if the disclosure aligned with general industry best practices or not.

Comment 6

[Andrew McCreight [:mccr8]]

Jens, do you know who might be available to fix this soon? Thanks.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

I guess we need to tweak the fix for bug 716491 a bit.

Comment 8

[Kershaw Chang [:kershaw]]

Thanks for taking this, Olli.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

Attachment: Bug 1723281, mark XHR load being an error load when send() fails, r=kershaw

Noticed similar issue with the blob uri, so fixed that in this patch too.
Tests are in the next patch.

InitiateFetch() call a bit later handles the marking for some other error cases.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

Attachment: Bug 1723281, add a test for unknown scheme and post on blob uri, r=kershaw

Depends on D130201

Comment 11

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

mark XHR load being an error load when send() fails, r=kershaw
https://hg.mozilla.org/integration/autoland/rev/b735ff2a23fd47ea0f2425f119e4f961e5cf8e5b
https://hg.mozilla.org/mozilla-central/rev/b735ff2a23fd

Comment 12

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

The patch landed in nightly and beta is affected.
:smaug, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

freddy, do you think we should uplift this?

Comment 14

[Frederik Braun [:freddy]]

The patch seems simple and I'm leaning towads yes.

Comment 15

[Jens Stutte [:jstutte]]

Hi Dragana, smaug is not here the entire week, could you please request uplift?

Comment 16

[Olli Pettay [:smaug][[e-mail]]]

I can do it :)

Comment 17

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 9248919 [details]
Bug 1723281, mark XHR load being an error load when send() fails, r=kershaw

Beta/Release Uplift Approval Request

• User impact if declined: Exposing registered URL schemes to web sites
• 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: So there is a testcase attached to the bug, but that hasn't landed. I wanted to wait a bit with that. Though, I guess the issue is known given the public web site.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): this should be low risk, because it is just tweaking an error case.
• String changes made/needed:

Comment 18

[Pascal Chevrel:pascalc (PTO until April 26)]

Comment on attachment 9248919 [details]
Bug 1723281, mark XHR load being an error load when send() fails, r=kershaw

Approved for 95 beta 8, thanks.

Comment 19

[Alexandru Trif, Desktop QA [:atrif]]

Hello! Can someone help to give some steps in order to reproduce and verify this manually?

I'm not sure what to do here, I loaded the javascript snippet from comment 0 in an affected build on https://playcode.io giving a Protocol NOT found: spotify://dummy console message and on a fixed build is giving a Protocol found: spotify://dummy console message, but I'm not sure that this is the right way.

Also, comment 17 is statting that a test case should be uploaded in near future. Thank you!

Comment 20

[Ryan VanderMeulen [:RyanVM]]

This ended up landing for 95.0b9.
https://hg.mozilla.org/releases/mozilla-beta/rev/18e4cff6fe01

Comment 21

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9248919 [details]
Bug 1723281, mark XHR load being an error load when send() fails, r=kershaw

Approved for 91.4esr also.

Comment 22

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr91/rev/3eef2fe29d57

Comment 23

[Alexandru Trif, Desktop QA [:atrif]]

Hello! Can you please help me with some steps to manually reproduce/ verify this issue? Thank you in advance,

Comment 24

[Olli Pettay [:smaug][[e-mail]]]

See the testcase, which I didn't land yet. I think I could land it now.

Comment 25

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

add a test for unknown scheme and post on blob uri, r=kershaw
https://hg.mozilla.org/integration/autoland/rev/326d58edc42519a7ed9079d7b53c2f353630f122
https://hg.mozilla.org/mozilla-central/rev/326d58edc425

Comment 26

[Frederik Braun [:freddy]]

Attachment: advisory.txt

Comment 27

[Frederik Braun [:freddy]]

We will be crediting you in the security advisories for our upcoming release of Firefox 95 as "smolikraphael".
Please respond to this needinfo request, if you wish to be credited differently (or not at all).

Comment 28

[smolikraphael]

The name would be ok, Raphael Smolik would be better.

Comment 29

[Frederik Braun [:freddy]]

Attachment: advisory.txt

Advisory text changed. Thank you :)

Comment 30

[Mihai Boldan, Desktop QA [:mboldan]]

Since we were not able to reproduce the issue, we are removing the qe+ flag, but if any additional information is added and QA is needed, please add again the qe+ flag.