1844025 - Logcat Exposes Sensitive Data via GeckoViewAutoFill in Focus (but not Fenix)

Status: RESOLVED FIXED

(Focus :: General, defect, P2)

Description

[Kent Bayron]

Attachment: Logcat.png

It is possible for data credentials to be leaked through GeckoViewAutoFill in Firefox Focus

Steps to Reproduce:

1. Install the most recent version of Firefox Focus: No Fuss Browser.
2. Launch the browser and navigate to Facebook or any other website.
3. Log in to your account and view the logcat entries.
4. Notice that GeckoViewAutoFill is unintentionally exposing the login credentials associated with my account.

App Version:
Firefox Focus 115.2.0 (Build 371912203)

URL visited:
https://m.facebook.com

Comment 1

[Andrew McCreight [:mccr8]]

Here's the logging that does this: https://searchfox.org/mozilla-central/rev/4537bb2abc8eb49506bbad27b89ab364ac3062d3/mobile/android/actors/GeckoViewAutoFillChild.sys.mjs#352

Comment 2

[Daniel Veditz [:dveditz]]

Chris: This was filed against "Focus", but since GeckoView is shared could you have Fenix tested for this as well? Not sure if this is actually a GeckoView problem or an issue with how Focus is using it (maybe a debug or logging setting was left on when it was built?)

Even apart from "sensitive" data like login credentials (obviously bad!!), this is a whole boatload of data that completely violates the premise of Focus as an "always private browsing" browser.

Is there a way for a user to turn on debugging mode? Maybe the reporter did that and forgot? I don't see an obvious user-facing setting in Focus to do that, but Gecko has plenty of debug-logging stuff that could be turned on if there's a switch somewhere.

Comment 3

[Daniel Veditz [:dveditz]]

Although this is not confirmed I'm going to proactively call this "sec-high" based on the claim.

Comment 4

[Matt Tighe [:matt-tighe]]

I've tested this in Focus, nightly and main branch Fenix and can only reproduce it in Focus for whatever reason.

Comment 5

[Matt Tighe [:matt-tighe]]

I will note that, AFAICT, this would require physical access to a device with an unlocked third party autofill service for it to be a real risk vector.

Comment 6

[Chris Peterson [:cpeterson]]

Matt recommends that Foundation engineer familiar with GeckoView investigate why GeckoView logging behaves differently in Fenix and Focus. I'm adding the [geckoview:m118?] whiteboard tag to get this bug on the Foundation team's radar.

Comment 7

[Sergey Galich [:serg]]

(In reply to Matt Tighe [:matt-tighe] from comment #5)

I will note that, AFAICT, this would require physical access to a device with an unlocked third party autofill service for it to be a real risk vector.

To me threat lies with user attaching debug logs in a public Bugzilla ticket without realizing it contains sensitive data.

Comment 8

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

The severity field for this bug is set to S3. However, the bug is flagged with the sec-high keyword.
:jonalmeida, could you consider increasing the severity of this security bug?

For more information, please visit BugBot documentation.

Comment 9

[Kent Bayron]

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #8)

The severity field for this bug is set to S3. However, the bug is flagged with the sec-high keyword.
:jonalmeida, could you consider increasing the severity of this security bug?

For more information, please visit BugBot documentation.

Agree with that, regarding Focus browser's data privacy, specifically concerning the extensive credentials leaks that seems to contradict its premise as an "always private browsing" browser.

Comment 10

[Kent Bayron]

Hello, Team! I hope all is well. Could you kindly provide me with an update on the current status of the issue?

Comment 11

[Kent Bayron]

Thank you for the update, Chris! Unfortunately, I don't have permission to access Jira. But, thanks anyway for the update!

Comment 12

[Kent Bayron]

Hi Team, Any update on this issue?
I am curious to ascertain whether this bug meets the criteria for a bounty reward?

Comment 13

[Kent Bayron]

Hello, Team! I hope all is well. Could you kindly provide me with an update on the current status of the issue?

Comment 14

[Kent Bayron]

Hi Team, Any update on this ?

Comment 15

[Andrew McCreight [:mccr8]]

Please don't needinfo a bunch of random people on a bug.

Comment 16

[Andrew McCreight [:mccr8]]

Chris, do you know who might be able to find somebody to work on this? It looks like there's been no progress since the initial verification 4 months ago. Thanks.

Comment 17

[Zac McKenney [:zmckenney]]

I can work on this and assigned myself.

Comment 18

[Zac McKenney [:zmckenney]]

This issue with logging was fixed in this revision from October which defaults the GeckoView logging from debug to warn unless a debug build of GeckoView is being used. In Firefox because we explicitly set debug logging in the runtime settings it was always either Debug or Fatal (based on Firefox configs). Since this runtime setting was missing in Focus the default GeckoView level was Debug. This is fixed now in GeckoView but I would suggest we update Focus runtime settings with the explicit call similar to Firefox which will increase the geckoview log level to Fatal instead of Warn. It is not required for this bug so I will create a separate bug and link the change to that.

Three major config changes in logging between Fenix and Focus release versions (all updated in future revision)

I enabled about:config in both release versions of Fenix and Firefox looking for differences.

• Focus sets geckoview.logging = Warn due to the change above and Fenix sets to Fatal (the default when not enabling debugLogging inside of GeckoRuntimeSettings Builder)
• Focus sets consoleservice.logcat = true instead of false
• Focus sets devtools.console.stdout.chrome = true instead of false

Comment 19

[Kent Bayron]

Thank you for keeping me in the loop and providing an update on the issue, sir Zac!

Comment 20

[Kent Bayron]

Hi Zac. Would love to know if is this eligible for a bounty? Thanks

Comment 21

[Andrew McCreight [:mccr8]]

(In reply to Kent Bayron from comment #20)

Hi Zac. Would love to know if is this eligible for a bounty? Thanks

The sec-bounty? flag has been set, so the bounty committee will likely consider it when they next meet. They usually meet once a week. Further questions about bounties are better asked in email to [e-mail], as the people managing the bounty program are unlikely to see Bugzilla comments. See more information on the bounty program here.

Comment 22

[Daniel Veditz [:dveditz]]

The bounty committee thinks my initial sec-high guess (based on worst-casing all assumptions, never corrected) is not correct. This logging is not available to other apps (unlike earlier versions of Android), and the logging could only be turned on by someone in possession of the phone and the ability to unlock it. Lowering to sec-moderate.

It is, however, an unintentional leak of sensitive data so we are awarding a bounty.

Comment 23

[Kent Bayron]

I'm happy to assist, thanks for the reward. Is it okay if I create a blog post addressing this problem?

Comment 24

[Daniel Veditz [:dveditz]]

Bulk-unhiding security bugs fixed in Firefox 119-121 (Fall 2023). Use "moo-doctrine-subsidy" to filter

Comment 25

[Kent Bayron]

Hey team, I'm thinking of writing a security write up blog for this issue, Is it okay? Thank you!