Firefox Focus security bug: "Use fingerprint to unlock app" bypass (new variant)
Categories
(Focus :: General, defect)
Tracking
(firefox135 wontfix, firefox136 verified, firefox137 verified)
People
(Reporter: bugzilla.mozilla.org, Assigned: mcarare)
References
Details
(Keywords: csectype-disclosure, reporter-external, sec-moderate, Whiteboard: [fixed in 1944771][client-bounty-form][adv-main136+])
Attachments
(2 files)
In Firefox Focus there is a setting that says "Use fingerprint to unlock app". When enabled, the user must first authenticate. The app should be locked if the user does not authenticate.
The bug is that this authentication step can be circumvented allowing fully access to the app (including browser history by pressing the "page back" button, and including the ability to switch to other open tabs).
I reported a similar bug earlier: bug 1895342 (CVE-2025-0245). I believe this bug is new, because:
- It can be triggered on version 134.0.1 and 134.0.2, and bug 1895342 is fixed in 134)
- It is not triggered in exactly the same way (requires clicking search widget 2 times instead of 1)
Steps to reproduce:
- Make sure that Firefox Focus has the "Use fingerprint to unlock app" setting turned on
- Use the app and then put it to the background (home button) or kill it completely (swipe up in task manager). When the app is started, user should authenticate first
- Long-press the desktop and add the search widget
- Quickly press the search widget, the home button and then the Firefox Focus icon
- Do it again: quickly press the search widget, the home button and then the Firefox Focus icon
- If done quickly enough, Firefox Focus will open without having to authenticate
I attached a movie showing the bug. I also put it online here: https://jurr.org/ff/video/Firefox%20Focus%20unlock%20bug%202.webm.
0:00 - 0:08: shows the "Use fingerprint to unlock app" is set
0:08 - 0:33: display the web page https://jurr.org/ff/ with explanation
0:33 - 0:41: add search widget
0:41 - end: Reproduce bug, open app without authentication. My first attempt failed because I misclicked - sorry!
Note that it does not matter if the app is only put into the background or completely killed ("swiped up in the task manager").
Confirmed on:
- Firefox Focus 134.0.2 (latest) on Android 13 (security update 05-11-2024)
- Firefox Focus 134.0.2 (latest) on Android 14 (a.k.a. "the Girlfriend's phone")
- Firefox Focus 134.0.1 on Android 11 (emulator - this is how the movie was recorded)
I'd be very happy to assist in any way I can. Please let me know how.
Updated•9 months ago
|
Comment 1•9 months ago
|
||
Mihai: what's different here from what you fixed in bug 1895342 / bug 1930512?
Assignee | ||
Comment 2•9 months ago
|
||
It seems to me like the same baseline issue when fast consecutive app openings are performed with a speed that manages to circumvent Android lifecycle events from completing, events that we are relying on to check if the lock is needed and place it.
The fix for the initial mentioned issue was meant to prevent this from happening. Just using the widget can reproduce the issue, but the number of consecutive openings might differ because you need to perform the action at a specific time when the method of "locking" the app is still executing. ( I can reproduce it on a Pixel with Android 13 after 5 or 6 consecutive app openings.)
So, I would say the cause is the same, even if the scenario differs slightly (less likely to be performed accidentally like before).
Reporter | ||
Comment 3•9 months ago
|
||
Hi Mihai,
You say this is likely the same baseline issue when fast consecutive app openings are performed with a speed that manages to circumvent Android lifecycle events from completing. This of course might very well be true. But I observe that bug 1895342 (CVE-2025-0245) is actually fixed. I can not get this to reproduce by doing just a single round of "search widget → home screen → Firefox Focus".
However, I am able to reliably reproduce this when doing that "search widget → home screen → Firefox Focus" twice. It's twice every time. So first time doesn't work, second time does, third time doesn't work, fourth time does, and so on. If this were an issue with speed and the Android OS not being able to keep up, I would expect much more erratic behavior.
I haven't looked at the code, so I'm not sure. But my gut feeling says this might be more then just timing or being too fast for the OS... What do you think?
Assignee | ||
Comment 4•9 months ago
|
||
Hi! Based on the arguments I presented in comment #2, I believe the issue has the same root cause. Moreover, it does not happen after a predetermined number of consecutive app openings on various devices that QA and I tested.
Assignee | ||
Comment 5•9 months ago
|
||
Fixed by 1944771.
Assignee | ||
Updated•9 months ago
|
Updated•9 months ago
|
Comment 6•9 months ago
|
||
Verified on the latest Focus Nightly 137.0a1 from 2/4, and on Focus Beta 136.0b1, with the following devices:
- Google Pixel 6 (Android 15),
- HTC 10 (Android 8), and
- Samsung Galaxy Note 8 (Android 9).
Updated•8 months ago
|
Updated•8 months ago
|
Comment 7•8 months ago
|
||
Updated•8 months ago
|
Updated•3 months ago
|
Description
•