1928779 - (CVE-2024-11703) Password manager device lock PIN bypass in Firefox 132.0 for Android

Status: RESOLVED FIXED

(Firefox for Android :: Logins, defect, P1)

Description

[yu270]

Firefox 132.0 on Android 15 allows a user to bypass the device lock PIN pop-up screen
and see all user passwords without entering the PIN.
The problem was found on a Pixel 8 with screen lock PIN in use and the "three button"
setting on the Android toolbar ("Back", "Home" and "Overview" buttons).
The "About Firefox" tab shows 132.0 (Build #2016051567).

Steps to reproduce:

1. Open Firefox 132.0 on Android 15.
2. On an empty tab, click the three-dot menu in the upper right corner.
3. Select "Passwords".
4. The screen that reads
   "Unlock your device

Unlock to view your saved passwords"
appears with an entry box, cursor and numerical keyboard.
5) Click the lower right "Overview" button (small square in shape).

Expected behavior: All running applications may be scrolled through, with the Firefox windows showing the "Unlock your device..." screen.
No passwords or websites are visible in Firefox.

Actual behavior: The "Unlock your device..." screen closes.
The Firefox window shows the "Saved passwords" page.
When clicking on Firefox to bring it to the foreground,
the Saved Passwords page is visible and individual sites may be selected,
revealing usernames and passwords.

The problem occurs in regular browsing or Incognito Mode.

Comment 1

[yu270]

The final sentence of the initial report should be "The problem occurs in regular browsing or private browsing mode."

Comment 2

[yu270]

On the same Android test device and software version,
the "Pattern" and "Password" screen lock settings can also be bypassed if enabled instead of "PIN."
The actual behavior is similar.

Follow steps 1, 2 and 3 in the initial report.

At step 4, the proper unlock screen appears for "Pattern" or "Password", like it does for "PIN."

Again in step 5, click the lower right "Overview" button.
The unlock screen disappears and the Saved Passwords page can be accessed without the unlock
pattern or password.

Comment 3

[Andrew McCreight (out of office until 8/21) [:mccr8]]

[Tracking Requested - why for this release]: seems like a bad security problem (possibly a regression?) that we appear to have at least two reports of (see bug 1928858) so it isn't a totally obscure thing.

Comment 4

[Andrew McCreight (out of office until 8/21) [:mccr8]]

[Tracking Requested - why for this release]: see comment 3

Comment 5

[Andrew McCreight (out of office until 8/21) [:mccr8]]

Alexendra, could somebody please investigate this? Thanks.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The bug is marked as tracked for firefox132 (release), tracked for firefox133 (beta) and tracked for firefox134 (nightly). However, the bug still isn't assigned.

:avirvara, could you please find an assignee for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 8

[Andrew McCreight (out of office until 8/21) [:mccr8]]

I can't reproduce this problem on Android 14. When I do the switch app thing (either via a gesture or via the square button, depending on how the navigation), the "Saved passwords" page does dismiss the fingerprint/PIN UI, but the page is completely black aside from the "Saved passwords" at the top, so the passwords are not visible.

Comment 10

[Andrew McCreight (out of office until 8/21) [:mccr8]]

Bug 1929017 has a video. In there, they switched away from the app by swiping up at the bottom of the screen to minimize the app. They said that it doesn't happen every time. I tried that method of switching away from the app, and I was able to reproduce on the first attempt on Android 14.

Comment 11

[yu270]

I found similar Firefox 132 behavior on Android 14 on a Pixel 5 (which reached end of Google support). Instead of swiping up like Andrew referred to in Bug 1929017, try the following:

Follow steps 1 through 4 in the original report for 1928779.
For step 5, click the Back button in the screen's lower left (small triangle) twice in rapid succession. This closes the lock screen UI unexpectedly and the Saved Passwords screen is visible.

The two clicks must be rapid, one after the other. And this is not a 100% reliable method to bypass the lock screen, in contrast to the original report about Android 15.

Comment 13

[Jeff Boek [:boek]]

Attachment: Bug 1928779 - removes else case in onResume

Comment 14

[Ryan VanderMeulen [:RyanVM]]

This feels pretty risky to take into a dot release in the next few days with minimal bake time. 133 seems like a better target.

Comment 17

[Donal Meehan [:dmeehan]]

Adding a reminder that we are near the end of the beta cycle for Fx133. The last beta builds on Friday 2024-11-15. If this can make the last beta build it would need to be reviewed, get sec approval, landed, and get an uplift request by eod Thursday 2024-11-14.

If this doesn't make Fx133 beta/RC then we could take it in an Fx133 dot release but it might need some bake time and coordinated with sec approval.

(:boek this assigned to Alexandra but the patch is yours)

Comment 18

[Jeff Boek [:boek]]

Thanks for the heads up :dmeehan. Coordinating with Alexandra right now on the correct fix.

Comment 19

[Alexandra Virvara]

Attachment: Bug 1928779: adapt screen content when device lock is bypassed SKIP_BMO_CHECK

Comment 22

[Frederik Braun [:freddy] (OOO until August 18th)]

We have a total of nine duplicate bug reports of this one. I think we should reconsider the priority settings to better reflect reality (I am aware that this has patches already reviewed).

Comment 25

[Alexandra Virvara]

Comment on attachment 9437169 [details]
Bug 1928779: adapt screen content when device lock is bypassed SKIP_BMO_CHECK

Security Approval Request

• How easily could an exploit be constructed based on the patch?: not so easy
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: No
• Which branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: nightly, beta - the status release flags reflect the state correctly
• If not all supported branches, which bug introduced the flaw?: Bug 1904652
• Do you have backports for the affected branches?: Yes
• If not, how different, hard to create, and risky will they be?:
• How likely is this patch to cause regressions; how much testing does it need?: the patch only adds some restrictions when displaying some private lists. it has been tested by devs so far
• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: Yes

Comment 26

[Alexandra Virvara]

Comment on attachment 9437169 [details]
Bug 1928779: adapt screen content when device lock is bypassed SKIP_BMO_CHECK

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: the issue has been reported many times in a short time
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: 1. Press 3-dot menu

2. Press Passwords and observe the biometric authenticator dialog
3. Send Fenix in background
4. Bring Fenix back in foreground

Expected Results: the biometric authenticator dialog should be shown
Actual Results: the biometric authenticator dialog has disappeared and one can see the saved passwords list without authentication.

• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The patch doesn't change the main behaviour in what biometric authentication is concerned, it only adds some restrictions when displaying some private info when users put the app in the background or when they try to bypass authentication.
• String changes made/needed:
• Is Android affected?: Yes

Comment 27

[Frederik Braun [:freddy] (OOO until August 18th)]

I am widening security bug access for this one to "release security", given that had some folks discuss this in various channels. There is little value in keeping this secret and I believe collaboration is easier without this as an unnecessary hurdle

Comment 28

[Daniel Veditz [:dveditz]]

Comment on attachment 9437169 [details]
Bug 1928779: adapt screen content when device lock is bypassed SKIP_BMO_CHECK

sec=approval+, a=dveditz

It's pretty obvious what's wrong from the patch, but with as many duplicates as we got in a week it was apparently obvious enough without the patch. No concerns about landing.

Comment 29

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7ea2889f55c4
adapt screen content when device lock is bypassed  SKIP_BMO_CHECK r=boek,android-reviewers

Comment 30

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

https://hg.mozilla.org/mozilla-central/rev/7ea2889f55c4

Comment 31

[Delia Pop (Android QA)]

Verified as fixed on Nightly 134.0a1 from 11/15 with Google Pixel 8 Pro (Android 14), Samsung Galaxy S22 Ultra (Android 14), Samsung GalaxyZ Fold 4 (Android 14) and Xiaomi Redmi Note 8T (Android 11). Although the lock screen can still be dismissed by tapping the back button or with gestures, the Password screen no longer shows the saved passwords.

Comment 32

[Donal Meehan [:dmeehan]]

Comment on attachment 9437169 [details]
Bug 1928779: adapt screen content when device lock is bypassed SKIP_BMO_CHECK

Approved for 133.0 rc1

Comment 33

[Pulsebot]

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

Comment 35

[yu270]

Following up to comment 31, Firefox Nightly version 134.0a1 is verified as fixed on the original test device (Pixel 8 running Android 15).
When sending Firefox to the background with the Overview button or with a gesture, the Saved Passwords screen no longer shows saved
usernames and passwords.

Comment 37

[Tom Ritter [:tjr] (OOTO until 9/2)]

Attachment: advisory.txt

We've received so many duplicates of this issue I'm not sure how to assign credit. I simply put it as "Multiple Reporters". If we wanted to name names, we would need to decide if we wanted to do first report (not in line with out duplicate reporting policy), overlap window (confusing to those not in the window), or list every person (difficult to coordinate and obtain names of all reporters.)

Comment 38

[Daniel Veditz [:dveditz]]

I initially assigned the severity "sec-high" based on user emotion, but our guidelines limit the severity because this requires physical access to the victim's unlocked phone.