Closed Bug 1751678 (CVE-2022-29915) Opened 2 years ago Closed 2 years ago

Detecting cross-origin redirects using the performance API

Categories

(Core :: Performance, defect, P3)

defect

Tracking

()

VERIFIED FIXED
100 Branch
Tracking Status
firefox-esr91 --- wontfix
firefox98 --- wontfix
firefox99 --- wontfix
firefox100 + verified

People

(Reporter: dattasohom1, Assigned: sefeng)

References

Details

(Keywords: privacy, sec-low, Whiteboard: [reporter-external] [client-bounty-form][post-critsmash-triage][adv-main100+])

Attachments

(3 files)

Attached file index.html

Found this while digging around while reporting a similar bug in Chrome. When advanced tracking protection is turned off, we can detect whether or not a cross-origin URL is a redirect using the difference of performance.getEntriesByName(...)[0].fetchStart - performance.getEntriesByName(...)[0].startTime.

Reproduction steps:

  1. Download the attached index.html file.
  2. Run a python HTTP server by running python -m http.server in the same directory as the index.html file.
  3. Open http://localhost:8000/index.html in Firefox
  4. Open the javascript console
  5. https://google.com should be correctly identified as a redirect, whereas, https://www.google.com should be identified as a URL without a redirect.
Flags: sec-bounty?
Group: firefox-core-security → dom-core-security
Component: Security → DOM: Core & HTML
Product: Firefox → Core
Summary: Decting cross-origin redirects using the performance API → Detecting cross-origin redirects using the performance API
Component: DOM: Core & HTML → Performance

NI myself for taking a look

Flags: needinfo?(sefeng)

Not sure what you mean by "advanced tracking protection is turned off"... is that just a typo for "enhanced" (ETP is disabled for the site) or do you mean it happens in "Standard" ETP as opposed to "strict" (advanced?) ETP? Odds are the first, but it's good to be clear.

Please let us know the link to the Chromium issue. I'm sure we can't see it if you've filed it as a security bug, but it's handy to be able to tie the issues later and double-check.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(dattasohom1)
Keywords: privacy, sec-low

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

Not sure what you mean by "advanced tracking protection is turned off"... is that just a typo for "enhanced" (ETP is disabled for the site) or do you mean it happens in "Standard" ETP as opposed to "strict" (advanced?) ETP? Odds are the first, but it's good to be clear.

It was a typo for "Enhanced Tracking Protection" :)

That being said, I appear to have misinterpreted the following warning Request to access cookie or storage on “<URL>” was blocked because it came from a tracker and content blocking is enabled. as the PoC not working. The exploit detects redirects with ETP enabled also. ETP is probably blocking 'credential': 'include' in my index.html PoC which caused the misunderstanding.

Please let us know the link to the Chromium issue. I'm sure we can't see it if you've filed it as a security bug, but it's handy to be able to tie the issues later and double-check.

https://bugs.chromium.org/p/chromium/issues/detail?id=1290150 is the bug (it is filed a security bug, yeah)

Flags: needinfo?(dattasohom1)
See Also: → 1754171

Chrome apparently landed a fix recently
https://chromium.googlesource.com/chromium/src/+/e96b9f57d8d9e32bf9cb748524735d7903271755%5E%21/
That includes also some changes to a wpt, so perhaps we have even a test for this.

Severity: -- → S3
Priority: -- → P3

Given the recent Fetch spec updates, Step 8.1 in
https://fetch.spec.whatwg.org/#finalize-and-report-timing specifies
that start time(StartTime) and post-redirect start time(FetchStart) should
be start time when TAO check fails.

Assignee: nobody → sefeng
Status: NEW → ASSIGNED
Flags: needinfo?(sefeng)
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 100 Branch
Flags: sec-bounty? → sec-bounty+
Group: dom-core-security → core-security-release
Flags: in-testsuite+
Flags: qe-verify+
Whiteboard: [reporter-external] [client-bounty-form] [verif?] → [reporter-external] [client-bounty-form] [verif?][post-critsmash-triage]

I tried to reproduce the issue on Firefox 98.0a1 (2022-01-24), and got this response:

On the latest Beta, 100.0b8, with the steps from Comment 0, is displayed:

From Comment 0, it doesn't look like the expected result. Is there anything that I'm missing, or is this the expected behavior?

Flags: needinfo?(dattasohom1)

(In reply to Mihai Boldan, QA [:mboldan] from comment #8)

I tried to reproduce the issue on Firefox 98.0a1 (2022-01-24), and got this response:

On the latest Beta, 100.0b8, with the steps from Comment 0, is displayed:

From Comment 0, it doesn't look like the expected result. Is there anything that I'm missing, or is this the expected behavior?

That is the expected behaviour (being unable to detect if a redirect has occured in the newer version)

Flags: needinfo?(dattasohom1)

Thanks Sohom Datta for the confirmation.
Based on the comments from above, I'm marking this issue as Verified Fixed.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Whiteboard: [reporter-external] [client-bounty-form] [verif?][post-critsmash-triage] → [reporter-external] [client-bounty-form][post-critsmash-triage][adv-main100+]
Alias: CVE-2022-29915
See Also: → CVE-2022-36316
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: