1450853 - (CVE-2020-15666) MediaError message property leaks cross-origin response status

Status: RESOLVED FIXED

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

Description

[gunesacar]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180208173149

Steps to reproduce:

1- Visit: https://output.jsbin.com/nejatopusi
2- Enter a URL in the input box, click the "Test" button
The URL will be loaded as the `src` of an audio element.


Actual results:

The message property of the MediaError interface contains a different string for resources that loads successfully. This allows an attacker to infer the response status for a cross-origin resource.



Expected results:

Cross-origin response status should not be detectable by scripts unless necessary CORS headers are sent by the server.

Comment 1

[gunesacar]

Detecting cross-origin response status can be used in various attacks such as inferring login status to various services, detecting servers on the LAN etc. 

The following paper from 2015 gives an overview of attacks that are enabled by a similar AppCache-based vulnerability: https://www.cc.gatech.edu/~slee3036/papers/lee:appcache.pdf

Comment 2

[gunesacar]

A clarification since this came up in the corresponding Chromium bug [1]: this attack works against any URL, not only audio/video contents.

[1] https://crbug.com/828265 (restricted)

Comment 3

[roxleitan]

Hi gunesacar,

I cannot reproduce the issue using Firefox 58.0 (Build ID: 20180208173149) and the latest Nightly 61.0a1 on Ubuntu 16.04 x64. (please see the attached screenshot) 

Could you please retest the issue using the latest Firefox Release 59.0.2 and the latest Nightly 61.0a1 and report back the result? Consider using a new clean Firefox profile (https://goo.gl/AWo6h8) as well as safe mode (https://goo.gl/AR5o9d), to eliminate custom settings as a possible cause.

If the issue is reproducible on your end, would you please attach a screenshot of the error?

Thanks

Comment 4

[roxleitan]

Attachment: error.png

Comment 5

[gunesacar]

I think the message in the demo page wasn't very clear. The error message displayed in your screenshot ("Failed to init decoder") means the cross-origin response is succeeded (hence the `Status: Success`).

I updated the demo page to be more explicit. Will also attach a screenshot.
https://output.jsbin.com/pocakoxede

Comment 6

[gunesacar]

Attachment: Demo - Mediaerror message cross-origin response status leak

Comment 7

[gunesacar]

Attachment: Demo source code - Mediaerror message cross-origin response status leak

Source code for the JSBin demo page at https://output.jsbin.com/pocakoxede

Comment 8

[gunesacar]

Just FYI, this bug also allows an attacker to discover IoT or other devices on the local network by probing device-specific URLs (e.g. home automation API endpoints): https://freedom-to-tinker.com/2018/06/21/fast-web-based-attacks-to-discover-and-control-iot-devices/

This is similar to attacks that exploit side effects of <img> or similar passive elements', but can be used to detect web interfaces that do not contain images.

Discovered devices can then be attacked by DNS rebinding. All can be done in under ten seconds.

Comment 9

[Sebastian Streich [:sstreich]]

Attachment: Bug 1450853 - Use Generic Error for 3rdparty MediaElement r=ckerschb

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6b518e88bdf9
Use Generic Error for 3rdparty MediaElement r=ckerschb,smaug

Comment 12

[Razvan Maries]

Backed out for perma failures.

Push with failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedTaskRun=dsGgzPx5TlutvoyheILWpA.0&resultStatus=pending%2Crunning%2Csuccess%2Ctestfailed%2Cbusted%2Cexception&searchStr=android%2C7.0%2Cx86-64%2Cwebrender%2Cdebug%2Creftests%2Ctest-android-em-7.0-x86_64-qr%2Fdebug-geckoview-crashtest-e10s%2Cc&revision=6b518e88bdf9f30c05c39694c134e16144293181

Logs:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=309729753&repo=autoland&lineNumber=4285
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=309728609&repo=autoland&lineNumber=3752
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=309734962&repo=autoland&lineNumber=2289

Backout: https://hg.mozilla.org/integration/autoland/rev/df41fdf433a3624be684bd225eae90e3c452c509

Comment 13

[Sebastian Streich [:sstreich]]

Fixed the problem, reftest is now green :)

https://treeherder.mozilla.org/#/jobs?repo=try&revision=9ddfa699aae7de36ae3e5b71cf612837bb926388

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b8f37ab63181
Use Generic Error for 3rdparty MediaElement r=ckerschb,smaug

Comment 15

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/b8f37ab63181

Comment 16

[Alex Catarineu (Tor Browser dev)]

Comment on attachment 9157433 [details]
Bug 1450853 - Use Generic Error for 3rdparty MediaElement r=ckerschb

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: We would like to have this patch in the next Tor Browser 10 based on ESR78. Uplifting it would mean one less patch to backport for us.
• User impact if declined: Tor Browser devs will have to backport the patch on top of ESR78 branch.
• Fix Landed on Version: 80
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The patch is minimal and only changes the error string for 3rd party loads.
• String or UUID changes made by this patch:

Comment 17

[Julien Cristau [:jcristau]]

Comment on attachment 9157433 [details]
Bug 1450853 - Use Generic Error for 3rdparty MediaElement r=ckerschb

approved for 78.2esr

Comment 18

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/f46af8bc88a4

Comment 20

[Tom Ritter [:tjr] (OOTO until mid-August)]

Attachment: advisory.txt