1740985 - (CVE-2022-22760) Detecting whether the content-type of a cross-origin resource is application/javascript through importScripts

Status: VERIFIED FIXED

(Core :: DOM: Workers, defect, P3)

Description

[Luan Herrera]

Attachment: index.html

It is possible to import external resources from within a Web Worker using the "importScripts" function, and by checking the error message, confirm whether the content-type is application/javascript or not.

The error message that is shown when a script failed to load due to having an incorrect content-type ("NetworkError: WorkerGlobalScope.importScripts: Failed to load worker script at https://victim.com/xyz.js (nsresult = 0x804b001d)") should be the same as when the script failed to load when having a correct content-type, but invalid syntax ("NetworkError: A network error occurred").

This vulnerability is useful for XS-Search attacks. A real-world example is https://medium.com/@luanherrera/xs-searching-googles-bug-tracker-to-find-out-vulnerable-source-code-50d8135b7549 (more on https://github.com/xsleaks/xsleaks/wiki/Real-World-Examples).

VERSION
Version: 94.0.1 (64-bit)
Operating System: Windows 10

REPRODUCTION CASE

1. Access https://lbherrera.github.io/lab/firefox/detect-js-53ffdde341/index.html
2. Click on the "check" button and a message confirming that the content-type of the resource is "application/javascript" will be displayed.
3. Change the URL to a resource that doesn't contain the "application/javascript" content-type set and click on the "check" button.

I have also attached the file used in the PoC - if you prefer, you can reproduce the attack by downloading and hosting index.html on a web server.

CREDIT INFORMATION
Reporter credit: Luan Herrera (@lbherrera_)

Comment 1

[Daniel Veditz [:dveditz]]

Christoph: would it be useful to have a meta bug to organize the XS-leaks issues?

Comment 2

[Christoph Kerschbaumer [:ckerschb]]

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

Christoph: would it be useful to have a meta bug to organize the XS-leaks issues?

Yes, I filed Bug 1742425 to do that.

Comment 3

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

https://searchfox.org/mozilla-central/rev/55a826a9ef74e92988e56cd9615d4fc6a470695e/dom/workers/ScriptLoader.cpp#2398-2399,2434-2437

Comment 4

[Jan Rio Krause]

The error message "NetworkError: A network error occurred" is triggered by ScriptExecutorRunnable::ShutdownScriptLoader.

Comment 5

[Jan Rio Krause]

Attachment: Bug 1740985 - Consistent error messages for scripts which failed to load. r=#dom-storage-reviewers

Comment 6

[Jan Rio Krause]

Additionally to my patch, I will write a test and land it later.

Comment 7

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

Consistent error messages for scripts which failed to load. r=dom-storage-reviewers,edenchuang
https://hg.mozilla.org/integration/autoland/rev/599ff51234bf387e66b0aa2c49aa47322f2be088
https://hg.mozilla.org/mozilla-central/rev/599ff51234bf

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for Beta and ESR approval when you get a chance.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Per Slack discussion with jkrause, this needs a bit more bake time than we have left in the current cycle.

Comment 10

[Hani Yacoub, Desktop QA]

Attachment: bug1740985.png

I'm attaching a print screen comparing the results of testing on Firefox Nightly 96.0a1 (2021-11-12) (Left) and the latest Firefox Nightly (right). I accessed the websites added in the description of the bug and also checked reddit.com.
I'm not sure of the verification I did is accurate and correct to verify the fix of this bug.
Could you please confirm if the results of the verification is correct to validate the fix?
Thanks.

Comment 11

[Jan Rio Krause]

Thank you for testing, Hani. Yes, the verification is accurate. The error message for an URL to a resource that contains the application/javascript content-type should be the same as the one that doesn't contain this content-type. Both should yield "NetworkError: A network error occurred." now.

The URL https://victim.com/xyz.js is a special case, because the hostname does not exist. This will be covered in Bug 1748503, among other things.

Comment 12

[Ryan VanderMeulen [:RyanVM]]

Is this ready for an ESR approval request? Please nominate if so.

Comment 13

[Hani Yacoub, Desktop QA]

Verified as fixed on Windows 10 x64, macOS 11.6 and on Ubuntu 20.04 x64.

Comment 14

[Jan Rio Krause]

Comment on attachment 9254798 [details]
Bug 1740985 - Consistent error messages for scripts which failed to load. r=#dom-storage-reviewers

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: It is possible to check whether a external resource has the content-type application/javascript or not. This vulnerability is useful for XS-Search attacks.
• User impact if declined: see above
• Fix Landed on Version: 97
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The fix just contains adding a case in a switch/case control structure for an error message. Thus, I consider the risk of uplifting as low.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9254798 [details]
Bug 1740985 - Consistent error messages for scripts which failed to load. r=#dom-storage-reviewers

Approved for 91.6esr.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr91/rev/24f825282cea

Comment 17

[Hani Yacoub, Desktop QA]

Verified as fixed on Firefox 91.6.0esr on Windows 10 x64, macOS 11.6 and on Ubuntu 20.04 x64.

Comment 18

[Hani Yacoub, Desktop QA]

I'm not sure why bug 1748503 was deleted from blocks. Please feel free to add it back if it's necessary.
Thanks.

Comment 19

[Tom Ritter [:tjr]]

Attachment: advisory.txt