1661617 - (CVE-2020-26965) Changing to <input type=password> to <input type=text> causes software keyboard type is changed to non-password style

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Makoto Kato [:m_kato]]

This may be privacy issue, I file as sec bug at first.

Actually, software keyboard type depends on current type attribute of input element. If type is password, we change to password layout. So if type attribute is changed, keyboard layout is also changed. This is managed by IMEStateManager to using type and inputmode.

But although some web site has "Show password' icon not to mask password input, the following issue occurs.

Env

Fenix with GBoard. I guess that this occurs on Windows tablet.

Step

1. Access to www.google.com
2. Enter google account email address.
3. Focus password field.
4. Click "Show password" icon.

Actual Result

Keyboard layout is changed to non-password style.

Actual Google Chrome Result

Even if tapping "Show password" icon, keyboard layout isn't changed. Although I heard from Googler that they consider this situation to keep keyboard layout for password.

I think that Chrome's way is better for password field. Although most software keyboard leans input history if not password layout, "Show password" causes that software keyboard learns inputted password even if this is password field as web site.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

they consider this situation to keep keyboard layout for password.

Even if focus is moved back again? And even if "Show password" is tapped before getting focus?

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(FYI: In the future, this should be solved without changing the type attribute.)

Comment 3

[Makoto Kato [:m_kato]]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #1)

they consider this situation to keep keyboard layout for password.

Even if focus is moved back again? And even if "Show password" is tapped before getting focus?

Set focus then tap "unmask password" icon.

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #1)

they consider this situation to keep keyboard layout for password.

Even if focus is moved back again? And even if "Show password" is tapped before getting focus?

Set focus then tap "unmask password" icon.

Only in the case we need to support, we can make IMEStateManager cache the first type value when setting IME context.

Comment 5

[:Gijs (he/him)]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #1)

they consider this situation to keep keyboard layout for password.

Even if focus is moved back again? And even if "Show password" is tapped before getting focus?

I think we have a hasBeenTypePassword property (webidl attribute) on input elements that can help fix this.

Comment 6

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

The severity field is not set for this bug.
:jstutte, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 7

[Makoto Kato [:m_kato]]

(In reply to :Gijs (he/him) from comment #5)

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #1)

they consider this situation to keep keyboard layout for password.

Even if focus is moved back again? And even if "Show password" is tapped before getting focus?

I think we have a hasBeenTypePassword property (webidl attribute) on input elements that can help fix this.

Yes, I try it.

Comment 8

[Makoto Kato [:m_kato]]

Attachment: Bug 1661617 - Use password hint for software keyboard.

Comment 9

[Makoto Kato [:m_kato]]

Attachment: test

Comment 10

[Makoto Kato [:m_kato]]

Comment on attachment 9177559 [details]
Bug 1661617 - Use password hint for software keyboard.

Security Approval Request

• How easily could an exploit be constructed based on the patch?: This is a kind of privacy issue. When using some web sites such as Google's login page, password field can change to non-masked input when clicking eye icon. Then, inputting password on this situation causes that software keyboard/IME learns input history unfortunately even if it is password. So, attacher have to access physical device to get password that is inputted.

Attacker knows that we set password style layout on some additional conditions from this fix, but it is no way to get password without accessing physical device.

• 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
• 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?: If text field was password type, and this field is re-used for other thing such as user name, the layout of software keyboard may keep password style.
  But I think that this is too rare case and this new behavior is same as Chrome for Android. So if regression occurs, Chrome will have also same issue.

Comment 11

[Tom Ritter [:tjr]]

Comment on attachment 9177559 [details]
Bug 1661617 - Use password hint for software keyboard.

No approval needed

Comment 12

[Makoto Kato [:m_kato]]

https://hg.mozilla.org/mozilla-central/rev/3b746525d6472490b44e55e4766078372e0380c3

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Is this something we should consider uplifting to ESR? It grafts cleanly.

Comment 14

[Makoto Kato [:m_kato]]

Attachment: Rebase for ESR78

Comment 15

[Makoto Kato [:m_kato]]

Comment on attachment 9185485 [details] [diff] [review]
Rebase for ESR78

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: This is privacy issue. IME might learn password input that text box was password box. (Ex. Google's login form can change non-masked input form for password.)
• User impact if declined: This is a kind of privacy issue. When using some web sites such as Google's login page, password field can change to non-masked input when clicking eye icon. Then, inputting password on this situation causes that software keyboard/IME learns input history unfortunately even if it is password. So, attacker have to access physical device to get password that is inputted.
• Fix Landed on Version: 83
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Low risk for most users. Most users don't use IME and this uses on Windows/Linux IME only.
• String or UUID changes made by this patch: no

Comment 16

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9185485 [details] [diff] [review]
Rebase for ESR78

Approved for 78.5esr.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/6bf26212d941

Comment 18

[Tom Ritter [:tjr]]

Attachment: advisory.txt