1892407 - (CVE-2024-9391) Jail users into Full Screen Mode no matter what key/function they press, they're trapped in regardlessly. (Firefox Focus for Android Lock Exit Fullscreen Mode)

Status: VERIFIED FIXED

(Focus :: General, defect, P2)

Description

[James Lee]

Attachment: jailfs.mp4

We are able to jail users persistently no matter what key/function they press allowing consistent full screen spoof even when tapping on Android back button repeatedly, for example.

Steps to reproduce:

1. Go to https://pwning.click/jailfs.php and tap on "Full Screen Mode"

2. Leave the browser and continue whatever tasks you were doing on your Android Phone on apps for a few minutes or longer.

3. When you come back to Focus, the app will reload and trap you into Full Screen Mode consistently no matter what key/function (e.g. back button) you press.

This has the same impact to this fixed sec-high issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1719088

Comment 1

[James Lee]

Attachment: jailfs.html

Comment 2

[Andrew McCreight [:mccr8]]

Sounds kind of bad so I'll mark it sec-high for now. The test case is also very simple which is not great. The demo page is blank, but I'm guessing it would be easy to put whatever content you want on the page and have the user see it. Maybe that's too high if the user is unable to interact with the page at all.

Comment 3

[James Lee]

Yeah and I confirmed that the page is fully interactive with HTML, js, css etc.

Comment 4

[Polly [:polly]]

I tried to reproduce this on a couple of Android 14 devices, with firefox nightly (v127) & steps:

• go to jailfs.html
• press fullscreen
• switch to another app using recents/home
• leave the phone for a while
• launch firefox using recents/launcher
  But I am always returned to the non-fullscreen view, so i don't get stuck as in the attached video.
  Other things I tried that had no effect:
• turn on Don't keep activities
• set background processes to 0
• release build of firefox (v125.3.0)
  Please could you provide more details of the device and OS used, or identify anything different about the steps i tried to reproduce this above?

Comment 5

[James Lee]

Hi Polly, please test this on Focus not Firefox since this is Focus bug.

Comment 6

[Polly [:polly]]

:) sorry, i missed that part!
Yes I can reproduce this in the latest Focus build (125.3.0) but not Firefox. thanks for the swift response!

Comment 7

[James Lee]

No problem, thank you for confirming swiftly, too!

Comment 8

[Polly [:polly]]

struggling to reproduce this reliably in focus after the one first time i saw it :(
if anyone can help provide clear repro steps, that would be super helpful

Comment 9

[Chris Peterson [:cpeterson]]

We can retest this fullscreen Focus bug after we fix the related Firefox bugs. Those Firefox fixes might fix this Focus bug or we can apply one of those Firefox fixes to Focus.

Comment 10

[James Lee]

Reproduce step is same, leave the phone for a while and come back.

Maybe try it after you Kill the Focus App or Restart the phone.

Comment 11

[Liz Henry (:lizzard) (privacy/fingerprinting team)]

Chris, what are the related Firefox bugs and do you think we could investigate this again since it has a sec-high rating?
Also, maybe it is worth retesting in a current version.

Comment 12

[James Lee]

I confirmed that this works on current version of Latest Focus Nightly too.

Comment 13

[Polly [:polly]]

Attachment: WIP: Bug 1892407 - Exit fullscreen on stop.

This is consistent with the Fenix behaviour.

Comment 14

[Polly [:polly]]

Attachment: Bug 1892407 - Exit fullscreen on stop.

This is consistent with the Fenix behaviour.

Comment 15

[Polly [:polly]]

i've managed to reproduce this now - thanks!
i've put up a suggested fix - basically just coming out of fullscreen mode when we transition out of having Focus in the foreground.
Does this sound ok to everyone? It's similar to what Fenix does...

Comment 16

[Polly [:polly]]

Comment on attachment 9417908 [details]
Bug 1892407 - Exit fullscreen on stop.

Security Approval Request

• How easily could an exploit be constructed based on the patch?: I guess if you had figured out why the patch is there, it would be fairly easy to make a website which puts you in fullscreen
• 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?: all
• If not all supported branches, which bug introduced the flaw?: None
• Do you have backports for the affected branches?: No
• If not, how different, hard to create, and risky will they be?: n/a
• How likely is this patch to cause regressions; how much testing does it need?: it's a one liner, pretty low risk
• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: Yes

Comment 17

[Daniel Veditz [:dveditz]]

Reproduce step is same, leave the phone for a while and come back.
Maybe try it after you Kill the Focus App or Restart the phone.

I haven't been able to reproduce either. What are your Focus settings? Your movie shows you stuck, but not how you get into that state.

One thing I learned is that the "Use fingerprint to unlock app" setting is incompatible with this testcase. So I've disabled that.

If I don't wait very long and the app is still running then Focus is still in fullscreen, but not stuck. If I wait long enough for Android to kill it (or I manually kill it myself as you suggest above) then focus comes up on the start page saying "browsing history was erased". Which is correct behavior as far as I know. I don't see any way to turn this off, but it's wholly consistent with the app being Private Browsing.

I assume your suggestion to "Restart the phone" was made off the cuff. If that didn't clear the stuck state then what did you do with the phone you show in the movie afterwards? Throw it away?

I don't see how the impact of this bug could be sec-high for a "private mode browser". unless it's permanently locking up your phone. Unlike normal Firefox, if Focus itself is permanently users can delete it and reinstall without losing any data.

Comment 18

[Daniel Veditz [:dveditz]]

Could it relate to an Android version difference? I've been trying to reproduce on Android 14 with the Samsung "One UI" version 6.1

Comment 19

[James Lee]

Polly was able to reproduce this on comment 6 and once again on comment 15

Whole video for Leaving app and coming back would be bigger size that's not uploadable here as just a few seconds of background apps screen recording eats up lot's of MB, but the point here is that as you can check from the PoC demo video, Focus refreshes itself when you reproduce this issue which results into stucking in Full Screen mode.

What I meant by restart or kill the app is not the step to reproduce this issue, but rather it's for refreshing the app to reproduce this bug as if we just installed the app, with no exceptions and different settings.

Browsing / checking other apps for less than a minute and coming back is enough to reproduce this issue. Probably there is a way to do this much shorter with certain way of rendering that'll cause to reload the app, maybe random garbage data causing lag could do a trick to make it work after just a few seconds. Regardless of that, it's common for users to use other apps and coming back to the browser as we know, I never heard example from anyone else that the app that will automatically killed after user left for certain time of period.

We could always reproduce this in "the first try" following the step and we're able to put up fully interactable page with fake facebook.com page for example, just like this sec-high bug 1719088

I'll provide that soon too when I get back to my device.

Comment 20

[James Lee]

tl;dr there's misunderstanding here and the step you just did is incorrect way to reproduce this issue and the points here are also misunderstood.

To reply on the reasoning of this is not serious because it's in "Private browser", this is not really the case because once user come back to browser just once there is only fake "facebook.com" or any legitimate site page without Full Screen Notification and stuck with it.

So like you said, yes, user can re-install or kill the app to escape that situation which are only two possible ways, but the screen page that user is watching is already fully spoofed page without Full Screen notification which is not exitable with back button and else, that is a full address bar spoofing and stuck in that state.

Comment 21

[Polly [:polly]]

hello! I reproduced the issue by basically following what i tried on comment 4.
It looks like the issue occurs when the Android OS decides to kill Focus, and then you switch back to it, so the OS 'reanimates' it from persisted state.
This can happen naturally, if you leave Focus, by either pressing home or using the recent apps switcher, and launch another memory-hungry app, then switch back to Focus.
But a more reliable way of making Android kill your app after use is to go into Developer Options:

• set Don't Keep Activities
• set Background Process Limit to 'No background processes'
  This is how i reproduced it & tested it when developing the fix.
  (Having said all that, for a while i did get into a situation where i couldn't reproduce it too... around comment 8... not sure how that happened. Possibly i was on a different device or missed a step somewhere?)
  For the record, this week I was able to reproduce it on a Samsung Galaxy S24 running Android 14, One UI 6.1 & latest dev build of Focus.
  I've made a couple of videos showing the situation before and after the fix, so i'll attach those, if that helps!

Comment 22

[Polly [:polly]]

Attachment: focus-jail-fullscreen-before.mp4

Comment 23

[Polly [:polly]]

Attachment: focus-jail-fullscreen-after.mp4

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ab64fd9533b8
Exit fullscreen on stop. r=android-reviewers,boek

Comment 25

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

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

Comment 26

[James Lee]

Attachment: Screen_Recording_20240821_175837_Firefox Focus.mp4

Thanks for the explanation and the way to trigger this immediately with no delay!

As per comment 3 and previous comment, we're able to trigger this with fully interactive page via this "kill" app behaviour ending up reloading the app with the page resulting to getting stuck in that spoofed legitimate site Full Screen state with no Full Screen notification, which is Full Address bar Spoofing with getting stuck on that spoofed fake legitimate site page.

This is because of the behaviour that "kill" app causing reload of the app and page which is same as page reload from the client side perspective which allows us to load the completely new spoof page when this is triggered.

You just need to call myFunction() when the page is loaded: window.onload = myFunction;

For the reason above, I don't see why this couldn't be rated as sec-high but please let me know if you think otherwise.

Thanks!

Comment 27

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

The patch landed in nightly and beta is affected.
:pollymce, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox130 to wontfix.

For more information, please visit BugBot documentation.

Comment 28

[Polly [:polly]]

i am not sure on the rating / uplift questions.... this bug has been around for a while, so it doesn't feel like we need to rush to get it into beta. I would feel safer letting it ride the trains, so i've marked it not for uplift. But please shout out if you disagree!

Comment 29

[Ryan VanderMeulen [:RyanVM]]

That'll be a question for Tom as the person who gave sec-approval. For sec-high bugs, we usually backport, though.

Comment 30

[Tom Ritter [:tjr] (OOTO until April)]

Given the obtuseness of the patch and where we are in the cycle I'm okay with letting it ride the trains to get more testing and confidence in it.

Comment 31

[James Lee]

comment 26, the fact that Android automatically killing background app won't actually kill Focus app but instead will trigger this bug of Full Screen Spoof with no notification resulting to Full Address bar Spoof and get stuck in that state is pretty bad since it's one of the worst impacts for spoofing type of attack.

On top of that, due to the page stuck in Full Screen behaviour, we are able to abuse this for different type of attack too, which would be not possible if it was just a Full Screen Spoof with no notification that we could exit from the spoof page with back button and others.

One example would be the Focus app asking for [Target] E-Mail and Password. As you can check from comment 26 with the demo video (while it's google.com here instead of Focus App asking, you get the idea which will be elaborated) https://bug1892407.bmoattachments.org/attachment.cgi?id=9420085&t=M4HJglpHVRTQa6HedNH9nB that shows we're opening the Focus browser freshly from Android home after Android automatically killing the app, user let Android automatically kill background Focus App and user freshly open Focus App from Android home, where user expecting empty tab with newly opened Focus but instead there is Full Screen Spoof page "Firefox Focus is asking for your [Target] E-Mail and Password to continue" in reality, which user can't escape the screen and that's very convincing "Focus App is asking for" spoof attack.

What would you do if you open Focus app freshly from Android home, that the Focus app you thought it was killed is asking for [Target] E-Mail and Password to continue while you can't change / get out of that screen? yes, user will never think this is from attacker's page as it's freshly opened from Android home after it was killed and trust that this is from Focus and thus will end up typing in them which will be sent to the attacker's server.

Like I mentioned, this type of attack is only possible because we have the "Full Screen Spoof with no notification and get stuck" behaviour where back button wouldn't reveal where we really are unlike just a normal Full Screen Spoof, allowing this type of "app is asking" attack since we know the example of apps sometime would require information before you proceed anythinig to use them where we can't cancel or bypass that step, just like this attack visually looks like that's exactly what's going on, where user can't change / escape the screen before entering in [Target] information since they think that this is from freshly opened Focus asking for that information.

Comment 32

[Daniel Veditz [:dveditz]]

Polly was able to reproduce this on comment 6 and once again on comment 15

Yes, I read her comments and saw her movies. They didn't help me reproduce it or tell me why I can't. That in turn doesn't give us any way to know what the impact of this bug might be on the population as a whole.

The Developer Mode options from comment 21 did finally let me reproduce the "stuck in fullscreen" effect, but of course I still have no way to know how commonly this would happen to people. Without those modes either I could go back to Focus and not get locked in, or Focus was so far killed by the OS that it restarted from the "history has been erased" home page. Anyway, now that I can reproduce it I can see that "stuck in fullscreen" doesn't mean users are trapped in the application: they can switch apps and kill Focus just fine; the fact that the back button doesn't work to exit full screen mostly contributes to spoof believability. While that might help in marginal cases, If the spoof is any good users wouldn't be checking.

I've always been able to reproduce the fact that users are still in full-screen when switching back (at least if you don't have the fingerprint lock feature enabled: comment 17) and that's really the core of the spoofing issue. And that's what Polly fixed.

Comment 33

[James Lee]

It seems like the main impact of this issue didn't really come across here since there is an important difference in behaviour when this was tested; "or Focus was so far killed by the OS that it restarted from the "history has been erased" home page."

For me, everytime Android automatic background app kill activates it reproduces this issue where Full Screen page get reloaded and get stuck there with fully actionable page when I freshly restart Focus browser as you can see from demo video in comment 26 https://bug1892407.bmoattachments.org/attachment.cgi?id=9420085&t=M4HJglpHVRTQa6HedNH9nB

I never used the way of setting The Developer Mode options to reproduce this issue but only let Android to kill Focus app on background.

Comment 36

[Jason Kratzer [:jkratzer]]

Attachment: advisory.txt

Comment 37

[Mira Lobontiu (Android QA)]

Verified as fixed on the Focus 136.0.2 build, Focus Beta 137.0b10, and on the Focus Nightly 138.0a1 from 3/25 with an Oppo Find N2 Flip (Android 14), and with a Samsung Galaxy Tab S9 Ultra (Android 14).