1653862 - (CVE-2020-15671) Firefox save gmail password into phone dicrtionarty

Status: VERIFIED FIXED

(GeckoView :: General, defect)

Description

[Karol Frejlich]

User Agent: Mozilla/5.0 (Android 8.0.0; Mobile; rv:79.0) Gecko/79.0 Firefox/79.0

Steps to reproduce:

Firefox version: 79.0.0-beta.9 Build #2015752523
Phone HW: Sony XPERIA XZ F8331
Android version: 8.0.0

Steps:

1. Open Gmail lagin page on Firefox Beta.
2. Enter login to Gmail (email)
3. Enter password to Gmail account

Actual results:

3.A. Entered password is shown above the virtual keyboard
3.B. Password was saved into Phone keyboard dictionary (it is available to see, ald it is proposed when writing On other pages/application)

IMPORTANT!
This issue does not occur on Firefox 68.10.1 (release on Google Play), that is why I think it is problem with Firefox Beta 79.0.0-beta.9

Expected results:

3.A Password should not be displayed when it is entering
3.B Password should not be saved into Phone keyboard dictionary

Comment 1

[Kevin Brosnan [Ex-Mozilla]]

Chenxia would you forward this to the correct person to investigate this?

Comment 2

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

What keyboard is being used? Can we verify this on a stock android phone?

Comment 3

[Kevin Brosnan [Ex-Mozilla]]

I can't reproduce this with the Google Keyboard. This might depend on the Xperia keyboard.

Comment 4

[Karol Frejlich]

Attachment: example

Comment 5

[Emily Kager [:ekager]]

We are already setting the flag IME_FLAG_NO_PERSONALIZED_LEARNING on all fields in GV GeckoEditable, which according to the docs is "used to request that the IME should not update any personalized data such as typing history and personalized language model based on what the user typed on this text editing object. Typical use cases are:

• When the application is in a special mode, where user's activities are expected to be not recorded in the application's history. Some web browsers and chat applications may have this kind of modes.
• When storing typing history does not make much sense. Specifying this flag in typing games may help to avoid typing history from being filled up with words that the user is less likely to type in their daily life. Another example is that when the application already knows that the expected input is not a valid word (e.g. a promotion code that is not a valid word in any natural language)."

One possibly relevant piece of info from the docs - "Applications need to be aware that the flag is not a guarantee, and some IMEs may not respect it."

The second thing I looked into is where we are setting the text flags by field hint in GeckoEditable. Password types get TYPE_TEXT_VARIATION_PASSWORD set on the inputType when it's a password field.

One thing we could try is adding TYPE_TEXT_FLAG_NO_SUGGESTIONS to the password fields as well, which according to the docs - "Flag for TYPE_CLASS_TEXT: the input method does not need to display any dictionary-based candidates."

There might be a valid reason we don't already add this flag, so NI-ing m_kato from GV team here.

Comment 6

[Karol Frejlich]

(In reply to Stefan Arentz | :st3fan | ⏰ EST | he/him from comment #2)

What keyboard is being used? Can we verify this on a stock android phone?

Used keyboard: Microsoft SwiftKey 7.5.9.3
I have attached screenshot that presents the problem. I have used example (not real :D) password "examplepasswod". As described in description, it was displayed and saved in phone dictionary.
I was thinking, that it could be issue on gmail page or keyboard, but on Firefox 68.10.1 it works fine.

Comment 7

[Kevin Brosnan [Ex-Mozilla]]

Using Firefox Nightly with the latest SwiftKey from GPlay. I am not seeing the information persist in the dictionary or suggested words. I am seeing the text that is being typed in the password field in some cases displayed in the suggestion area. Submitting the password results in the password field being treated as expected with IME_FLAG_NO_PERSONALIZED_LEARNING and subsequent typing does not trigger the suggestions.

• first run
• if the user taps the eye icon in the password field
• clearing private data

Comment 8

[Kevin Brosnan [Ex-Mozilla]]

I can reproduce the same behavior in Reference Browser and Focus. I cannot reproduce what I see in comment 7 in Chrome.

Comment 9

[Makoto Kato [:m_kato]]

IME_FLAG_NO_PERSONALIZED_LEARNING means that IME doesn't record input history for suggestion. This is for guest session, or private mode. So this isn't related.

When looking this screen shot, keyboard layout on Swift Key isn't for password style. (Password layout style of Swift Key has number keys.)

When I test this, this sometimes occur, but not always. When this issue occurs, focus already is gotten on password field, but when this doesn't occur, no focus when showing password field on this site.

After that, when re-focus to password field, it can change to valid keyboard correctly. I think InputContext doesn't pass valid input type from IMEStateManager, or GeckoEditable doesn't initialize keyboard layout per EditorInfo for this situation.

But this issue depends on web content and I need analyze gmail's user name and password navigation.

Comment 10

[Kevin Brosnan [Ex-Mozilla]]

Should we open this up? I'm not seeing any great harm to users in this issue currently.

Comment 11

[Makoto Kato [:m_kato]]

Attachment: Bug 1653862 - Set InputContext after getting focus.

This is timing issue to set InputContext that is used by setting keyboard
layout.

InputContext is set by chrome process only. Since we want to use it on
child process, we store cached value by NOTIFY_IME_OF_FOCUS. But before
setting it, we may use old cached value unfortunately.

So we have to wait until valid cached InputContext is set.

Also, I add some assertions for this check.

Comment 12

[Makoto Kato [:m_kato]]

Comment on attachment 9167814 [details]
Bug 1653862 - Set InputContext after getting focus.

Security Approval Request

• How easily could an exploit be constructed based on the patch?: It isn't easy since this is timing issue, but this can reproduce on account.google.com.
• 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 older supported branches are affected by this flaw?: all (this issue occurs on GV only)
• If not all supported branches, which bug introduced the flaw?: None
• 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?: Low risk. When setting focus by user operation, this issue doesn't occurs and we don't use this code path of this bug.
  If we need manual test, we should test on login form of google.com, facebook.com, microsoft.com and major sites.

Comment 13

[Tom Ritter [:tjr]]

Comment on attachment 9167814 [details]
Bug 1653862 - Set InputContext after getting focus.

sec-low does not require sec-approval to land :)

Comment 14

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

https://hg.mozilla.org/integration/autoland/rev/b4ed6e66a889ef0772ed635eb0af737fd6f4ee85
https://hg.mozilla.org/mozilla-central/rev/b4ed6e66a889

Comment 15

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for Beta approval.

Comment 16

[Makoto Kato [:m_kato]]

Ryan, doesn't "Product: Fenix" has approval-mozillla-beta? (Or should I move product to GeckoView since this fix is GV?)

Comment 17

[Makoto Kato [:m_kato]]

(I cannot find approval-mozilla-beta flag in attachment. My env issue?)

Comment 18

[Ryan VanderMeulen [:RyanVM]]

Moving it into GeckoView makes sense IMO. Try now :-)

Comment 19

[Makoto Kato [:m_kato]]

Comment on attachment 9167814 [details]
Bug 1653862 - Set InputContext after getting focus.

Beta/Release Uplift Approval Request

• User impact if declined: When setting focus to password field by web site script automatically, software keyboard may not change to password field style. Most software keyboard learns input history if not password field, so it may be that your password is stored in software keyboard's input history.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: 1. Open Gmail login page.

2. Enter login to Gmail (email)
3. Enter password to Gmail account

• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): When user sets focus by user operation, this issue isn't related to this code path. When setting focus to password field by web site script automatically, we don't set software keyboard immediately at this situation. It is set after getting current text control style.
• String changes made/needed: no

Comment 20

[Julien Cristau [:jcristau]]

Comment on attachment 9167814 [details]
Bug 1653862 - Set InputContext after getting focus.

gv fix, approved for 80 rc1

Comment 21

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-release/rev/d198d17488a6

Comment 22

[Diana Rus]

Hi,reproduced the issue partially and only when the password is visible in the field with Sony Xperia Z5 (Android 7) and Google Pixel 3 XL (Android 9) with the latest Microsoft SwiftKey keyboard from playstore (version 7.6.0.9) on Firefox Beta 79.0.0-beta.9

• I encountered the display of the password while being inserted in the field, in the suggestion area, also suggestion area could be enabled when tapping on the (eye) symbol from password field for gmail domain so that the password is visible. (Point 3.A from actual result-description)
• Didn't encounter point 3B from actual result-description.

On Firefox Preview Release 80.0.1 RC.1 - I can still see what is inserted in the field in case the user let's the password visible to UI - please check video, otherwise the suggestion area for the password field is hidden but it's the same case as for Firefox Beta 79.0.0-beta.9

@ Makoto - should this be happening - the suggestion area be available when the password is visible to UI?

Comment 23

[Makoto Kato [:m_kato]]

(In reply to Diana Rus from comment #22)

@ Makoto - should this be happening - the suggestion area be available when the password is visible to UI?

What version of GeckoView of Firefox Preview Release 80.0.1 RC.1? I have verified by the latest Nightly.

Comment 24

[Tom Ritter [:tjr]]

Given that this is an issue in a beta product, I'm going to exclude it from the advisories.

Comment 25

[Tom Ritter [:tjr]]

We had begun rolling out Fenix 79.

Comment 26

[Diana Rus]

Hi Makoto, for Firefox Preview Release 80.0.1 RC.1 has the following GV: 80.0-20200818235255, the AC: 54.0.3, c91a47caa and AS: 61.0.10.

In the meantime a new build has arrived 80.1.0 (Build #2015759937) that has the same GV as Build 80.0.1 RC1 and with AC: 54.0.4, 60a32c926, AS: 61.0.10 for which the same outcome is present as the one mentioned in Comment22. Checked with same devices Google Pixel 3 XL (Android 9) and Sony Xperia Z5 (Android 7).

Did a check on Nightly 8/25 with GV: 81.0a1-20200820093209 and encountered the same outcome as for Firefox Preview 80.1.0, created a new issue here: https://github.com/mozilla-mobile/fenix/issues/14162

I'll mark this as verified as when for gmail when the the "eye symbol" is uncut (password not visible in UI)

Comment 27

[Makoto Kato [:m_kato]]

(In reply to Diana Rus from comment #26)

Hi Makoto, for Firefox Preview Release 80.0.1 RC.1 has the following GV: 80.0-20200818235255, the AC: 54.0.3, c91a47caa and AS: 61.0.10.

In the meantime a new build has arrived 80.1.0 (Build #2015759937) that has the same GV as Build 80.0.1 RC1 and with AC: 54.0.4, 60a32c926, AS: 61.0.10 for which the same outcome is present as the one mentioned in Comment22. Checked with same devices Google Pixel 3 XL (Android 9) and Sony Xperia Z5 (Android 7).

Did a check on Nightly 8/25 with GV: 81.0a1-20200820093209 and encountered the same outcome as for Firefox Preview 80.1.0, created a new issue here: https://github.com/mozilla-mobile/fenix/issues/14162

I'll mark this as verified as when for gmail when the the "eye symbol" is uncut (password not visible in UI)

Wait. This issue is hidden due to security issue. Why do you file the bug to public space?

Comment 28

[Makoto Kato [:m_kato]]

And Where Build 80.0.1 RC1 to check this?

Comment 29

[Makoto Kato [:m_kato]]

Diana, although you click "show password" icon, why do you click this? If clicking it, password is show and keyboard layout isn't password layout type. It is correct behavior now. And I don't write this step on comment #19.

step

1. Access www.google.com
2. Click [Sign in]
3. Enter google account address and then [Enter]
4. Password field is shown, so tap Android's back key (to close software keyborad) and tap Android's back key (to navigate to previous page)
5. Enter google account address and then [Enter]

Comment 30

[Chenxia Liu [:liuche]]

Hi Diana, I got a request to delete the version of this security issue filed in Github because it might create a security risk - please file security issues in bugzilla in the future! That way we can discuss and fix and not worry about exploits built off of filed bugs.

Comment 31

[Diana Rus]

Hi,
@ Chenxia - sure, thank you
@ Makoto - you can take the Firefox Preview builds from here:

• https://github.com/mozilla-mobile/fenix/tags
• https://firefox-ci-tc.services.mozilla.com/tasks/index/mobile.v2.fenix.nightly.latest - Firefox Preview Nightly
• https://firefox-ci-tc.services.mozilla.com/tasks/index/mobile.v2.fenix.beta.latest - Firefox Preview Beta
• https://firefox-ci-tc.services.mozilla.com/tasks/index/mobile.v2.fenix.release - Firefox Preview RC

(In reply to Makoto Kato [:m_kato] from comment #29)

Diana, although you click "show password" icon, why do you click this? If clicking it, password is show and keyboard layout isn't password layout type. It is correct behavior now. And I don't write this step on comment #19.

step

1. Access www.google.com
2. Click [Sign in]
3. Enter google account address and then [Enter]
4. Password field is shown, so tap Android's back key (to close software keyborad) and tap Android's back key (to navigate to previous page)
5. Enter google account address and then [Enter]

Thank you for creating issue 1661617(i don't have access at the moment for it). I know that it is a different scenario, that is why i've asked about it in Comment22 and created a new issue to have track of it.

(In reply to Diana Rus from comment #22)

@ Makoto - should this be happening - the suggestion area be available when the password is visible to UI?

I think that issue can be closed, based on your response.

The original STR's (can be seen in the starting of the video from Comment22) and the one you mentioned in Comment29, alongside a couple of other domains, have been checked and it's all good.

Hope this clarifies a bit the situation. Thank you

Comment 32

[Makoto Kato [:m_kato]]

@ Makoto - you can take the Firefox Preview builds from here:

I verified the fix by Firefox Preview RC (80.1.1 Build #2015760555) and Firefox Nightly.