Closed Bug 1621853 (CVE-2020-6824) Opened 1 year ago Closed 1 year ago

Generated passwords are shared between separate private sessions of the same browser session

Categories

(Toolkit :: Password Manager, defect, P2)

Desktop
All
defect

Tracking

()

VERIFIED FIXED
mozilla76
Tracking Status
firefox-esr68 --- unaffected
firefox73 --- wontfix
firefox74 --- wontfix
firefox75 --- verified
firefox76 --- verified

People

(Reporter: MattN, Assigned: MattN)

References

Details

(Keywords: sec-moderate, Whiteboard: [adv-main75+])

Attachments

(2 files, 1 obsolete file)

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.

Flags: qe-verify+
Assignee: nobody → MattN+bmo
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla76

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

Maybe Timea can verify the fix with the two STR?

Flags: needinfo?(tbabos)

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.

Flags: needinfo?(tbabos)

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

Flags: needinfo?(MattN+bmo)

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
Flags: needinfo?(MattN+bmo)
Attachment #9132787 - Flags: approval-mozilla-beta?

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

Attachment #9132787 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Group: firefox-core-security → core-security-release
QA Whiteboard: [qa-triaged]

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

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+
Alias: CVE-2020-6824

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

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.

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?

(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.

Group: core-security-release
You need to log in before you can comment on or make changes to this bug.