1842030 - (CVE-2023-4583) After closing the last Private Window, context is not always reset/cleared...

Status: RESOLVED FIXED

(Firefox :: Private Browsing, defect, P2)

Description

[Thejaka Maldeniya]

Regression of Bug 1585306

I have previously reported the regression a long time ago, but it hasn't been addressed yet.

See previous STR first.

I have now found new STR:

1. Open a new Firefox instance. Alternatively, start by closing all private windows and tabs.

2. Open two successive (empty) tabs, loading Google in each.

3. Close the entire private window that contains the two tabs.

4. Immediately after closing in step 3, open a new private window and navigate to Gmail.

Expected Result: The Gmail login page (see original STR screenshot) should be loaded.

Actual Result: The Gmail home page (see original STR screenshot) is loaded.

The original screenshots may be different from the current screens, but should suffice.

As a security and privacy issue, I wonder why this hasn't been addressed sooner.

Comment 1

[Tim Huang[:timhuang]]

Thanks for reporting,

I have some questions regarding the STR.

In step 2, should the two tabs be opened inside a private window? Do we need to sign in for these two tabs?

In step 3, how fast do we need to open a new private window? I am wondering if this is a time racing issue.

Last, do you test these with permanent private browsing enabled?

Thanks,

Comment 2

[Thejaka Maldeniya]

Sorry, I hadn’t stated it clearly.

Yes, the two tabs have to be opened as private.
The first can be opened by using “New private window” from hamburger menu.
The second tab can be opened using the + for new tab.
Alternatively, I guess you could use bookmarks.

Time seems to be irrelevant. I have waited for more than a minute or so.

No, I haven’t enabled permanent private browsing.

Updated STR:

1. Open a new Firefox instance. Alternatively, start by closing all private windows and tabs.

2. Open a private window and open a second private tab as well, loading Google in each tab.

3. Close the entire private window that contains the two tabs.

4. After closing in step 3, open a new private window and navigate to Gmail.

Comment 3

[Tim Huang[:timhuang]]

We try to reproduce this issue with the updated steps, but we couldn't successfully reproduce it. Would you be able to provide your troubleshooting information on your about:support page to help us analyze the issue? Thanks.

Comment 4

[Thejaka Maldeniya]

Attachment: Application Basics ------------------ Name: Firefox Version: 115.0.2 Build ID: 20230710165010 Distribution ID: Update Channel: release User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0 OS: Windows_NT 10.0 22621

Note:

Comment 5

[Thejaka Maldeniya]

Note: When closing in step 3, close the entire window with the X on the window. not the tabs individually.

Comment 6

[Tim Huang[:timhuang]]

Attachment: Bug 1842030 - Part 1: Adding CanonicalBrowsingContext::IsPrivateBrowsingActive(). r?nika!

The CanonicalBrowsingContext::IsPrivateBrowsingActive() function allows
us to know if private browsing is active. We need it to prevent setting
cookies if there is no active private browsing session.

Comment 7

[Tim Huang[:timhuang]]

Attachment: Bug 1842030 - Part 2: Don't set cookies for private channels if there is no active private browsing session. r?#necko

Depends on D184010

Comment 8

[Tim Huang[:timhuang]]

Attachment: Bug 1842030 - Part 3: Add a test to ensure a beacon response for a private session won't set cookie after private session ends. r?#anti-tracking

Depends on D184011

Comment 9

[Tim Huang[:timhuang]]

Attachment: Bug 1842030 - Part 2: Check the global private browsing state for HttpBaseChannel::IsBrowsingContextDiscarded() if the loadGroup is not avaiable. r?#necko

The HttpBaseChannel::IsBrowsingContextDiscarded() did always return
false if the loadGroup is not avaiable. But, this may not be correct for
the private channels if the private session has been ended. To fix this,
we make the function to check the global private browsing state
if the loadGroup is not available for private channels.

Depends on D184010

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b26aeacc05b3
Part 1: Adding CanonicalBrowsingContext::IsPrivateBrowsingActive(). r=nika
https://hg.mozilla.org/integration/autoland/rev/bb290a3bdead
Part 2: Check the global private browsing state for HttpBaseChannel::IsBrowsingContextDiscarded() if the loadGroup is not avaiable. r=necko-reviewers,jesup
https://hg.mozilla.org/integration/autoland/rev/62a2a4cf426a
Part 3: Add a test to ensure a beacon response for a private session won't set cookie after private session ends. r=anti-tracking-reviewers,pbz

Comment 11

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/b26aeacc05b3
https://hg.mozilla.org/mozilla-central/rev/bb290a3bdead
https://hg.mozilla.org/mozilla-central/rev/62a2a4cf426a

Comment 12

[Ina Popescu, Desktop QA]

Unfortunately I was not able either to reproduce this issue by following the STR mentioned in Comment 2.
Thejaka, could you please check if the issue no longer persists in the latest Nightly 117.0a1 version? Thanks

Comment 13

[Ryan VanderMeulen [:RyanVM]]

It sounds like we might want to uplift this to ESR115? Please nominate if yes - it grafts cleanly.

Comment 14

[Tim Huang[:timhuang]]

Comment on attachment 9344673 [details]
Bug 1842030 - Part 1: Adding CanonicalBrowsingContext::IsPrivateBrowsingActive(). r?nika!

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: The bug affects the users who are using private windows in ESR.
• User impact if declined: Cookies could leak across different private browsing sessions.
• Fix Landed on Version: 117
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The fix is small and doesn't change user behaviors.

Comment 15

[Monica Chiorean]

I am not able to reproduce the issue on Win11 using FF build 115.0.2 and the steps provided in comment#2, so I can not confirm the fix.
Reporter, can you please verify the fix on build 115.2.0esr (https://archive.mozilla.org/pub/firefox/candidates/115.2.0esr-candidates/build1/win64/). Thank you.

Comment 16

[June Wilde (she/her) [:jewilde]]

Attachment: advisory.txt

Comment 17

[Donal Meehan [:dmeehan]]

Comment on attachment 9344673 [details]
Bug 1842030 - Part 1: Adding CanonicalBrowsingContext::IsPrivateBrowsingActive(). r?nika!

Approved for 115.3esr.

Comment 18

[Donal Meehan [:dmeehan]]

Comment on attachment 9344675 [details]
Bug 1842030 - Part 3: Add a test to ensure a beacon response for a private session won't set cookie after private session ends. r?#anti-tracking

Approved for 115.3esr.

Comment 19

[Donal Meehan [:dmeehan]]

Comment on attachment 9345569 [details]
Bug 1842030 - Part 2: Check the global private browsing state for HttpBaseChannel::IsBrowsingContextDiscarded() if the loadGroup is not avaiable. r?#necko

Approved for 115.3esr.

Comment 20

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/155e00db2f45
https://hg.mozilla.org/releases/mozilla-esr115/rev/a5e801062c13
https://hg.mozilla.org/releases/mozilla-esr115/rev/9d8a85f62f6d

Comment 21

[Daniel Veditz [:dveditz]]

Sorry for the burst of bugspam: filter on tinkling-glitter-filtrate
Adding reporter-external keyword to security bugs found by non-employees for accounting reasons