Closed Bug 1450853 (CVE-2020-15666) Opened 3 years ago Closed 2 months ago

MediaError message property leaks cross-origin response status

Categories

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

58 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla80
Tracking Status
firefox-esr78 --- fixed
firefox80 --- fixed

People

(Reporter: gunes.acar, Assigned: sstreich)

References

Details

(Keywords: csectype-sop, parity-chrome, sec-low, Whiteboard: [domsecurity-backlog2][adv-main80+])

Attachments

(5 files)

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.
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
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)
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
Flags: needinfo?(gunes.acar)
Attached image error.png
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
Flags: needinfo?(gunes.acar)
Component: Untriaged → DOM: Security
Product: Firefox → Core
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Whiteboard: [domsecurity-backlog2]
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.
Assignee: nobody → sstreich
Status: NEW → ASSIGNED
Pushed by rmaries@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6b518e88bdf9
Use Generic Error for 3rdparty MediaElement r=ckerschb,smaug
Flags: needinfo?(sstreich)
Pushed by abutkovits@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b8f37ab63181
Use Generic Error for 3rdparty MediaElement r=ckerschb,smaug
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla80

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:
Attachment #9157433 - Flags: approval-mozilla-esr78?

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

approved for 78.2esr

Attachment #9157433 - Flags: approval-mozilla-esr78? → approval-mozilla-esr78+
Whiteboard: [domsecurity-backlog2] → [domsecurity-backlog2][adv-main80+]
You need to log in before you can comment on or make changes to this bug.