Closed Bug 1731614 (CVE-2022-34477) Opened 3 years ago Closed 2 years ago

MediaError message property leaks information on cross-origin same-site pages

Categories

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

Firefox 92
defect

Tracking

()

RESOLVED FIXED
102 Branch
Tracking Status
firefox-esr91 - wontfix
firefox100 --- wontfix
firefox101 --- wontfix
firefox102 + fixed

People

(Reporter: jannis, Assigned: jewilde)

Details

(Keywords: csectype-sop, sec-low, Whiteboard: [domsecurity-backlog1][adv-main102+])

Attachments

(4 files)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:92.0) Gecko/20100101 Firefox/92.0

Steps to reproduce:

  1. Download the attached HTML page
  2. Run a server on port 9898 in the download directory: e.g., python3 -m http.server 9898 or php -S 0.0.0.0:9898
  3. Go to http://localhost:9898/firefox_media_error.html
  4. Observe the results
  5. Start another server on port 9999 in the directory: e.g., python3-m http.server 9999
  6. Observe the results

Actual results:

The cross-origin response with different ports (same-site) leaks information in the MediaError message property. In step 4, this response error message is 2152398861: Request failed. In step 6, this response error message is 404: File not found.

Expected results:

According to https://bugzilla.mozilla.org/show_bug.cgi?id=1450853 the MediaError message property should be Failed to open media for all cross-origin responses to prevent XS-Attacks such as login detection.
For cross-site pages and same-site pages with different subdomains, the fix implemented in https://hg.mozilla.org/integration/autoland/rev/6b518e88bdf9 works. For same-site pages with different ports, the fix is not applied and an attacker has access to the same values as a same-origin page.

It also works for same-site pages with different subdomains.
I incorrectly concluded it does not work as it fails for localhost and sub.localhost as they are treated as different sites.
If one changes localhost to example.com, the leaks also work for subdomains such as sub.example.com.

To reproduce in Linux:

Group: core-security → dom-core-security

sstreich, do you know why this code is doing a check on ThirdParty() and not something else? Thanks.

It looks like in Chrome they call into some WouldTaintOrigin() method that isn't a same origin check, but also isn't a third party check.

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/public/platform/web_media_player.h;drc=8f95b5eab2797a3e26bba299f3b0df85bfc98bf5;l=234

Flags: needinfo?(sstreich)

It definitely shouldn't be a "same site" check, but why wouldn't it be a simple same-origin check? Not sure why Chrome uses WouldTaintOrigin()

In any case, it's an easy fix.

Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
Whiteboard: [domsecurity-active]

I think the fix would be to update mSrcAttrTriggeringPrincipal->IsThirdPartyURI to mSrcAttrTriggeringPrincipal->IsSameOrigin.

Basti can you please take that on?

Assignee: nobody → sstreich
Assignee: sstreich → nobody
Priority: P2 → P3
Whiteboard: [domsecurity-active] → [domsecurity-backlog1]
Flags: needinfo?(sstreich)

June volunteered to take a look - thanks!

Flags: needinfo?(jewilde)
Assignee: nobody → jewilde
Status: NEW → ASSIGNED
Flags: needinfo?(jewilde)
Group: dom-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 102 Branch
QA Whiteboard: [post-critsmash-triage]
Flags: qe-verify-
Whiteboard: [domsecurity-backlog1] → [domsecurity-backlog1][adv-main102+]
Flags: sec-bounty-hof+
Alias: CVE-2022-34477
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: