Open Bug 1611534 Opened 2 years ago Updated 2 years ago

Cross-origin information leakage via cross-origin window frame count

Categories

(Core :: DOM: Core & HTML, defect, P5)

74 Branch
defect

Tracking

()

People

(Reporter: avinash.sudhodanan, Unassigned)

Details

(Keywords: sec-want, Whiteboard: [tor 33155])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36

Steps to reproduce:

I created a web page that opens a cross-origin URL using the window.open method. The URL pointed to a linkedin profile. I then made my web page print the number of frames within the opened window (using the window.length method).
//Sample code below
win = window.open("https://www.linkedin.com/in/avinash-sudhodanan-82a238113");
setTimeout(function(){wind.length}, 5000);

Actual results:

I noticed that the number of frames read by my web page leaks sensitive information cross-origin. For instance, the frame-count is 3 when
I am logged in at the opened profile, and it is 4 otherwise. Meaning, a controversial web site (e.g., a web site for pornography or same-sex dating) can leverage this leak to determine whether a specific Linkedin user (e.g. a politician, a CEO, or an actor) is visiting the site. I quickly reported this leak to Linkedin and they immediately fixed the issue.
I noticed that the same leak has been leveraged in other attacks to leaks sensitive info. (e.g., see https://www.imperva.com/blog/facebook-privacy-bug/, https://www.imperva.com/blog/mapping-communication-between-facebook-accounts-using-a-browser-based-side-channel-attack/ and https://portswigger.net/research/abusing-chromes-xss-auditor-to-steal-tokens).

Expected results:

Firefox should not have allowed cross-origin frame-count reads.
Eric Lawrence from Microsoft pointed out https://bugs.chromium.org/p/chromium/issues/detail?id=752190 and mentioned that this is one of the side-channels baked into the standard.
When I noticed that the issue also affects the Tor browser, I decided to report it to them as they are more privacy-sensitive than standard browsers.
They replied the following.

Indeed Tor Browser is a privacy-sensitive browser, however part of Tor Browser's current mission is integrating as many privacy protections and enhancements as possible directly into Firefox. This is a process Mozilla should lead because plugging this leak requires a specification change. This is a perfect example of where Mozilla can propose a change through the new Privacy Community Group at the W3C. Tor Browser should inherit the solution from Firefox instead of introducing additional changes that break existing web functionality.

Please let us know when you have a ticket for this bug. Thanks!

Hence I am reporting this leak here. We conducted a detailed study on such leaks and an early report of our results is available at https://arxiv.org/abs/1908.02204.

The Chrome issue is public, and I assume so is the study. Is there any reason this issue should stay hidden?

Group: firefox-core-security → dom-core-security
Component: Untriaged → DOM: Core & HTML
Flags: needinfo?(avinash.sudhodanan)
Product: Firefox → Core

(In reply to :Gijs (he/him) from comment #1)

The Chrome issue is public, and I assume so is the study. Is there any reason this issue should stay hidden?

No, it need not stay hidden.

Flags: needinfo?(avinash.sudhodanan)

Anne, is this already being considered in the appropriate standards venues? If not, who could lead such an effort? Is Eric Lawrence's assertion in https://bugs.chromium.org/p/chromium/issues/detail?id=752190#c1 that there are compat reasons we cannot break this behaviour outright, only based on opt-ins from the target site, still true, and if so, does such an opt-in mechanism exist today?

Group: dom-core-security
Flags: needinfo?(annevk)

Sites can mitigate this with the experimental Cross-Origin-Opener-Policy header (for popups, there's nothing for framed sites). That header is meant to address this class of attacks. There's some hope we can start enforcing Cross-Origin-Opener-Policy by default in the future, once sites that need this kind of relationship to work have adopted it and opt-out of its protections (i.e., explicitly set it to its current default value of unsafe-none). There's no concrete plan or timeline for that as of yet though.

Flags: needinfo?(annevk)

Hi Anne,
Thank you for your reply. The plan to enforce a default cross-origin opener policy sounds very much like the default SameSite=Lax cookie policy enforcement in browsers. In this regard I have a question. Even before SameSite cookies were introduced, Tor has been treating cookies as if they had SameSite=Lax enabled. Given this trend, and considering that Tor is very privacy-sensitive, do you recommend that it starts enforcing a default cross-origin opener policy?

Flags: needinfo?(annevk)

It would prevent certain "XSLeaks" popup-based attacks, but it would also break a number of sites as things are today. It seems safer to start enforcing this once Cross-Origin-Opener-Policy is further along.

Flags: needinfo?(annevk)

annevk: Could you set the priority of this bug?

Flags: needinfo?(annevk)

I'd be inclined to resolve this as INVALID/WONTFIX until there's a feasible plan to change the standard, but given that Tom added sec-want, let's keep it as P5 for now.

Flags: needinfo?(annevk)
Priority: -- → P5
Whiteboard: [tor 33155]

Matt, if we spoofed window.length = 0 under a default-off pref, would the Tor Browser be interested in flipping it?

Flags: needinfo?(sysrqb)

(In reply to sanketh from comment #9)

Matt, if we spoofed window.length = 0 under a default-off pref, would the Tor Browser be interested in flipping it?

Yes! We'd enable it and see what breaks.

Flags: needinfo?(sysrqb)

Create a new default-off static pref
privacy.resistFingerprinting.spoofWindowLength and spoof window.length to zero
when it is true. Create
dom\tests\mochitest\resistfingerprinting\test_spoofWindowLength.html to test
this behavior.

Assignee: nobody → sanketh

This doesn't seem that meaningful to me as a determined attacker would try/catch their way through window[index] to find the upper bound.

(In reply to Anne (:annevk) from comment #12)

This doesn't seem that meaningful to me as a determined attacker would try/catch their way through window[index] to find the upper bound.

Fair point. We are investigating this. The patch is on hold till we can figure this out.

Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #9153330 - Attachment description: Bug 1611534 - Spoof window.length to zero under a default-off pref r?tjr → Bug 1611534 - In RFP mode, spoof window.length of cross-origin windows to zero r?tjr
Assignee: sanketh → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.