2027572 - (CVE-2026-12320) Login export with a primary password set does not re-prompt for the primary password

Status: RESOLVED FIXED

(Toolkit :: Password Manager, defect)

Description

[Av0id]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:149.0) Gecko/20100101 Firefox/149.0

Steps to reproduce:

1. mettre en place un mot de passe principal
2. cliquer sur "paramètres"
3. cliquer sur "mots de passe enregistrés"
4. cliquer sur "exporter les mots de passes"

Actual results:

L'export à fonctionné sans vérification supplémentaire, me permettant d'accéder aux mots de passes en clair

Expected results:

Exiger le mot de passe principal avant de permettre cet export

Comment 1

[Daniel Veditz [:dveditz]]

Like Gijs I fully expected to find this on file already, but I can't find any past bugs about export.

Comment 2

[Johannes [:joschmidt]]

Strictly speaking, we are talking about two mechanisms here:

1. the encryption of usernames and passwords using a key protected by the primary password
2. the protection of the UI

The former has no timeout, so passwords can be decrypted until the end of the session after the primary password is entered once.

To secure access to critical data via the UI during runtime, we use OS authentication. This has been recently standardized in 1991050.

In that sense, the primary password is not bypassed, but definitely should be complemented by additional protections, like is done eg for about:logins.

Comment 3

[:Gijs (he/him)]

Things like bug 1939916 or bug 1967681 have previously not even gotten a sec-rating. Does this really deserve sec-moderate? As Johannes noted, the user would still have needed to enter the primary password to unlock the passwords in the first place.

Comment 4

[Daniel Veditz [:dveditz]]

I don't know how to answer that. The general behavior and default settings of our password manager is from the "Web 2.0" era and isn't up to best practices in many ways. Is that a security problem? Is it fine because we've always done it that way?

Every time a user visits the about:logins page we require them to enter their password to reveal passwords, even if they've entered their primary password before. We ask for their OS login even if they don't use a primary password at all! We've considered ways to get around that to be security bugs in the past, and the bulk export of passwords is more equivalent to the about:logins case than the slower site-by-site password gathering represented by the two bugs you mention above. Johannes said bug 1991050 standardized on using the OS password once the primary password is unlocked and sure, that would be fine, too. Consistency is good!

There is no reasonable way to un-authenticate the primary password (and I suspect bug 1991050 took away my hacky way to do it). Users concerned enough to use a primary password would consider this a serious problem. The whole point of the primary password is to protect your passwords from people with local access so it doesn't seem right to discount the severity too much because this bug requires local access.

Comment 5

[:Gijs (he/him)]

I guess it might be moot, because in fact I cannot reproduce.

STR:

1. set primary password
2. restart browser for good measure (but I doubt it's needed)
3. open about:logins. You're prompted for primary passwords before the page even shows any passwords. Provide the pwd.
4. try to export passwords. You get a warning dialog. Accept it. Then, before asking for a location to save them, you're prompted again.

Am I missing something?

Comment 6

[Johannes [:joschmidt]]

Attachment: (secure)

Comment 7

[Johannes [:joschmidt]]

Found the issue:
the fallback to prompting for the primary password when OS auth is disabled was broken: if the primary password was already unlocked in the session, requestReauth would silently authorize without showing any dialog.

Comment 8

[Johannes [:joschmidt]]

Could this be related?

Comment 9

[Johannes [:joschmidt]]

Comment on attachment 9569291 [details]
(secure)

Security Approval Request

• How easily could an exploit be constructed based on the patch?: Moderate. The patch reveals the bypass condition for csv export authentication, but requires physical access to a running Firefox instance with this exact configuration; not remotely exploitable.
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: Unknown
• Which branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: Beta, Release, ESR
• If not all supported branches, which bug introduced the flaw?: Bug 1991050
• Do you have backports for the affected branches?: No
• If not, how different, hard to create, and risky will they be?: Low risk. The change is small (5 files, mainly parameter removal), so backports should be straightforward if requestReauth has a similar shape in older branches.
• How likely is this patch to cause regressions; how much testing does it need?: Low; the only behavior change is in the previously-untested edge case, which is now covered by a new browser test.
• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: No

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/90865a09f546
https://hg.mozilla.org/integration/autoland/rev/b4622f751ee7
prompt for primary password on re-auth when OS auth is disabled r=simonf,credential-management-reviewers,dimi

Comment 11

[Ryan VanderMeulen [:RyanVM]]

(In reply to Johannes [:joschmidt] from comment #9)

• Which branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: Beta, Release, ESR
• If not all supported branches, which bug introduced the flaw?: Bug 1991050

Bug 1991050 landed in Fx149. Is ESR really affected? If it is, do we have the correct regressor?

Comment 12

[Johannes [:joschmidt]]

1991050 is the right regressor, ESR falsely marked as affected.

Comment 13

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

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