Closed Bug 1661617 (CVE-2020-26965) Opened 10 months ago Closed 8 months ago

Changing to <input type=password> to <input type=text> causes software keyboard type is changed to non-password style

Categories

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

Unspecified
All
defect

Tracking

()

RESOLVED FIXED
83 Branch
Tracking Status
firefox-esr78 83+ fixed
firefox82 --- wontfix
firefox83 + fixed

People

(Reporter: m_kato, Assigned: m_kato)

References

(Depends on 1 open bug)

Details

(Keywords: sec-low, Whiteboard: [adv-main83+][adv-esr78.5+])

Attachments

(4 files)

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.

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?

Flags: needinfo?(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.

Flags: needinfo?(m_kato)

(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.

(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.

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(jstutte)

(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.

Assignee: nobody → m_kato
Attached patch testSplinter Review

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.
Attachment #9177559 - Flags: sec-approval?

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

No approval needed

Attachment #9177559 - Flags: sec-approval?
Status: NEW → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED
Group: core-security → core-security-release
Target Milestone: --- → 83 Branch

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

Flags: needinfo?(m_kato)
Attached patch Rebase for ESR78Splinter Review

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
Flags: needinfo?(m_kato)
Attachment #9185485 - Flags: approval-mozilla-esr78?

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

Approved for 78.5esr.

Attachment #9185485 - Flags: approval-mozilla-esr78? → approval-mozilla-esr78+
Whiteboard: [adv-main83+]
Flags: needinfo?(jstutte)
Whiteboard: [adv-main83+] → [adv-main83+][adv-esr78.5+]
Alias: CVE-2020-26965
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.