Last Comment Bug 1100154 - You can pass information between named windows in Private Browsing and the main process using targeted links
: You can pass information between named windows in Private Browsing and the ma...
Status: VERIFIED FIXED
[lang=c++][adv-main43-]
: csectype-disclosure, sec-low
Product: Firefox
Classification: Client Software
Component: Private Browsing (show other bugs)
: 33 Branch
: x86_64 Linux
-- normal (vote)
: Firefox 43
Assigned To: Aidin Gharibnavaz
:
: :Ehsan Akhgari (super long backlog, slow to respond)
Mentors: Josh Matthews [:jdm]
: 1155962 1215904 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-11-16 13:01 PST by Daniel Roesler
Modified: 2016-03-21 05:22 PDT (History)
15 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
wontfix
verified
wontfix


Attachments
Proof of concept. Follow directions in the file. (2.59 KB, text/html)
2014-11-16 13:01 PST, Daniel Roesler
no flags Details
1100154.patch (1.08 KB, patch)
2015-08-14 19:09 PDT, Aidin Gharibnavaz
bzbarsky: review+
Details | Diff | Splinter Review
1100154.patch (1.14 KB, patch)
2015-09-05 09:15 PDT, Aidin Gharibnavaz
no flags Details | Diff | Splinter Review

Description User image Daniel Roesler 2014-11-16 13:01:03 PST
Created attachment 8523555 [details]
Proof of concept. Follow directions in the file.

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

Steps to reproduce:

1. Create a webpage with a link targeting a named window (e.g. <a href="/" target="foo">Click Here!</a>).

2. Open that webpage in both normal and private browsing modes.

3. Click on the link in one of the two modes. It should open a new tab with the target name.

4. Click on the link in the other of the two modes.



Actual results:

When clicking on the link in the other of the two modes, the named window in the first mode loads the desired page. The loaded page has access to all of that mode's resources (localStorage/cookies/etc.).


Expected results:

Window names should not be shared between normal and private browsing modes. This allows you to pass information between those two modes.
Comment 1 User image Daniel Roesler 2014-11-16 13:04:10 PST
This trick works in Firefox on both Linux and OSX. It does not work in Chromium.
Comment 2 User image :Gijs 2014-11-17 07:47:25 PST
Ehsan/Josh, are you aware of this issue?
Comment 3 User image Josh Matthews [:jdm] 2014-11-17 07:52:38 PST
No, but I'm not surprised. This doesn't need to be security-sensitive, however.
Comment 4 User image Josh Matthews [:jdm] 2014-11-17 07:58:11 PST
Presumably nsDocShell::DoFindItemWithName would be the important place that needs to change in order to avoid this.
Comment 5 User image Daniel Roesler 2014-11-17 09:17:47 PST
The most obvious use case for this bug that I see is for websites to try and find out who throwaway accounts are (common on Reddit, HN, etc.). This could be harmful for people who think they can just pop open a private browsing window and create a throwaway account.
Comment 6 User image Josh Matthews [:jdm] 2014-11-17 12:31:16 PST
I'm willing to help anybody who would like to investigate this. Stepping through DoFindItemWithName should make it clear what's going wrong, and where we should be comparing mInPrivateBrowsing against another docshell's GetUsePrivateBrowsing value.
Comment 7 User image Anirudh GP(:anirudhgp) 2015-01-25 02:41:22 PST
Hi I'd like to try and help with this bug. Where do I begin looking for the fix?
Comment 8 User image Michael Ratcliffe [:miker] [:mratcliffe] 2015-04-23 02:35:25 PDT
(In reply to Anirudh GP(:anirudhgp) from comment #7)
> Hi I'd like to try and help with this bug. Where do I begin looking for the
> fix?

Sounds to me like you need to ask jdm.
Comment 9 User image Daniel Roesler 2015-08-02 00:24:10 PDT
FYI, I put together a demo of the exploit on github.

https://diafygi.github.io/detect-throwaways/index.html
Comment 10 User image Aidin Gharibnavaz 2015-08-14 19:09:46 PDT
Created attachment 8648329 [details] [diff] [review]
1100154.patch

The attachment fixed the demo "Daniel Roesler" created.

Here's the output of the Try Server:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=74e850bb0c3e

It runs all of the Mochitests, and everything seems OK. The failed ones seems un-related to my changes.
Comment 11 User image Josh Matthews [:jdm] 2015-08-16 08:31:17 PDT
Thanks Aidin! I'm going on vacation for a week, so you should probably ask someone else like :smaug for review.
Comment 12 User image Aidin Gharibnavaz 2015-08-17 01:12:33 PDT
Seems that :smaug, and other reviewers are also on vacation or busy! I will wait a week. There's no problem.
Comment 13 User image Boris Zbarsky [:bz] (work week until 5/26) (if a patch has no decent message, automatic r-) 2015-09-04 10:44:23 PDT
Comment on attachment 8648329 [details] [diff] [review]
1100154.patch

The patch looks great.  The commit message could use some improvement.  How about:

  Bug 1100154 - Ensure that targeted links in a private browsing window can't target non-private-browsing windows and vice versa.

?

r=me.
Comment 14 User image Aidin Gharibnavaz 2015-09-05 09:15:44 PDT
Created attachment 8657451 [details] [diff] [review]
1100154.patch

Thanks for the review (:

I update the commit message. Nothing else changed.
Comment 16 User image Carsten Book [:Tomcat] 2015-09-07 03:47:27 PDT
https://hg.mozilla.org/mozilla-central/rev/0ddcebe7cc4f
Comment 17 User image :Ehsan Akhgari (super long backlog, slow to respond) 2015-10-28 11:39:06 PDT
*** Bug 1215904 has been marked as a duplicate of this bug. ***
Comment 18 User image Khalid Syfullah Zaman [:khalid32] 2015-11-08 03:04:02 PST
I have reproduced this bug on Nightly 36.0a1 (2014-11-16) on ubuntu 14.04 LTS, 32 bit!

The bug's fix is now verified on Latest Beta 43.0b1!

Build ID: 20151103023037
User Agent: Mozilla/5.0 (X11; Linux i686; rv:43.0) Gecko/20100101 Firefox/43.0

[bugday-20151104]
Comment 19 User image Josh Matthews [:jdm] 2015-11-08 06:39:05 PST
Thanks Khalid!
Comment 20 User image Bogdan Maris, QA [:bogdan_maris] 2015-11-09 06:49:28 PST
Confirming this fix under Mac OS X 10.11.1 and Windows 7 64-bit too, with 43.0b1 build 2 (Build ID: 20151103023037). Thanks for verifying, Khalid!
Comment 21 User image [:philipp] 2016-02-12 01:49:55 PST
hi, do you think this change can be related to the crash in bug 1247872 which would be regressing since firefox 43?
Comment 22 User image :Gijs 2016-02-12 02:17:39 PST
(In reply to philipp from comment #21)
> hi, do you think this change can be related to the crash in bug 1247872
> which would be regressing since firefox 43?

I *think* so. bz, is this just the load context being null?
Comment 23 User image Boris Zbarsky [:bz] (work week until 5/26) (if a patch has no decent message, automatic r-) 2016-02-12 06:42:05 PST
Sure looks like it.  I'll follow up in bug 1247872.
Comment 24 User image Marco 2016-03-21 05:22:33 PDT
*** Bug 1155962 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.