1621853 - (CVE-2020-6824) Generated passwords are shared between separate private sessions of the same browser session

Status: VERIFIED FIXED

(Toolkit :: Password Manager, defect, P2)

Description

[Matthew N. [:MattN]]

STR A:
Pre-req.: Have a non-private browser window open.

1. Open a private window
2. Generate a password on a website (e.g. using the context menu)
   Don't edit it or interact with the doorhanger
3. Close the private window (leaving Firefox still open e.g. due to an existing non-private window)
4. Open a new private browsing window
5. Visit the same website as step 2 and generate a password again

Expected result:
The generated password is different than in step 2 since I'm in a separate private browsing session.

Actual result:
The same generated password will be used since it was cached in LoginManagerParent and it didn't listen for the last-pb-context-exited observer notification. A user may accidentally use the same password on two accounts in two private browsing session unintentionally.

Related problem: Generated passwords remain in memory when the last private window is closed, even if they weren't auto-saved.

STR B:

1. Save a password with no username for a site.
2. Follow steps 1–3 above for the same site

Expected result:
Since a login with no password was already saved, the user wasn't told the password would be auto-saved (and it shouldn't be) and therefore the user thinks there are no traces of this site on their computer if they choose not to save the generated password manually.

Actual result:
The generated password is persisted in memory along side the origin in memory until the browser is shut down. The password and/or origin could be extracted from memory or via privileged code in browser developer tools.

Comment 1

[Matthew N. [:MattN]]

Attachment: Bug 1621853 - Clear password generation cache upon last-pb-context-exited. r=sfoster

Comment 2

[Matthew N. [:MattN]]

https://hg.mozilla.org/integration/autoland/rev/a1771d7b1b8f9aada3a762b8bd81f48f2affccb5

Comment 3

[Matthew N. [:MattN]]

https://hg.mozilla.org/mozilla-central/rev/a1771d7b1b8f9aada3a762b8bd81f48f2affccb5

Comment 4

[Matthew N. [:MattN]]

It might be worth uplifting this if it bakes fine on Nightly.

Maybe Timea can verify the fix with the two STR?

Comment 5

[Timea Cernea [:tbabos][inactive]]

Reproduced the issue on affected Nightly builds on Windows 10 x64.
It is fixed in Nightly build 76.0a1 (2020-03-13) (64-bit)(Build ID: 20200313042424) on Windows 10 x64 for both STR.
Every time a new private window is opened, a new password will be generated.

Will verify further when it is uplifted in Beta.

Comment 6

[Matthew N. [:MattN]]

Thanks! I'll request uplift on Monday/Tuesday if I see no regressions.

Comment 7

[Matthew N. [:MattN]]

Comment on attachment 9132787 [details]
Bug 1621853 - Clear password generation cache upon last-pb-context-exited. r=sfoster

Beta/Release Uplift Approval Request

• User impact if declined: Closing the last private window won't clear the generated password used or the store in memory which includes the origin. Opening a separate private session will re-use the same password on the same origin which may lead to unintended password reuse.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Fairly straightforward deletion from a Map using an existing observer notification.
• String changes made/needed: None

Comment 8

[Julien Cristau [:jcristau]]

Comment on attachment 9132787 [details]
Bug 1621853 - Clear password generation cache upon last-pb-context-exited. r=sfoster

sec fix for generated passwords in private windows, approved for 75.0b5

Comment 9

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-beta/rev/b25e2637b29e

Comment 10

[Timea Cernea [:tbabos][inactive]]

Verified-fixed on latest Beta 75.0b7 on Windows 10 x64, Ubuntu 16.04 and MacOS 10.13.

Comment 11

[Tom Ritter [:tjr]]

Attachment: advisory.txt

Comment 12

[Tom Ritter [:tjr]]

Attachment: advisory.txt

Comment 13

[Frederik Braun [:freddy]]

Are we doing something to help people detect and change those duplicate passphrase when affected?

Comment 14

[Matthew N. [:MattN]]

No, we have no good way of doing so and this kind of an edge case to have two different PB windows that you want to segregate in the same session or for the same website. The generated password is also shown to the user before they fill it (at least in recent versions where it all goes through autocomplete) so users could have noticed on their own but nobody reported it.

Comment 15

[Frederik Braun [:freddy]]

Well, we can check for duplicate / re-used passwords. It's, of course, another thing to find if those have been automatically generated. So, I take that bit is not stored anywhere?

Comment 16

[Matthew N. [:MattN]]

(In reply to Frederik Braun [:freddy] from comment #15)

Well, we can check for duplicate / re-used passwords. It's, of course, another thing to find if those have been automatically generated. So, I take that bit is not stored anywhere?

Correct, we don't store whether a password was generated. Bug 1118553 is about general duplicate/re-use warnings.