New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 2 users

Issue metadata

Status: WontFix
Closed: Jan 2018
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , iOS , Chrome , Mac , Fuchsia
Pri: 2
Type: Bug-Security

Sign in to add a comment

Issue 802993: Security: Do not send autofill data to renderer process until user acts on form

Reported by, Jan 17 2018 Project Member

Issue description


Per mathp@, Chrome's autofill feature sends a preview of autofill data (such as credit card numbers) to the renderer process before the user selects data via a browser process UI.  This allows the data to appear as the user hovers over the suggestion.

Due to Spectre, JavaScript code may be able to read arbitrary memory in the renderer process, allowing it to read such autofill values as the page is loaded, before the user has actually selected them.  In theory, this could be used to steal autofilled credit card numbers, etc.

We should ensure that autofill data is not sent to the renderer process at all until the user takes some specific action indicating that they want to add it to the form on the page.

Chrome Version: 63.0.3239.132 stable
Operating System: Win/Mac/Linux/ChromeOS

Comment 1 by, Jan 17 2018

Components: UI>Browser>Passwords

Comment 2 by, Jan 17 2018

Labels: -Pri-1 Pri-2
I've attached a video of the preview and select mechanisms for Autofill so we are on the same page.

* When the user hovers over the suggestion in our browser-side UI, the data is put in the input field's shadow DOM.
* When the user selects the suggestion (end of the video), the data is put directly in the field. It looks identical to the preview phase.

For the purposes of this vulnerability, in both hover and select cases the data is in the renderer process and could be obtained via Spectre.

The Password manager works similarly for the purposes of this vulnerability, at various stages using Shadow DOM and/or setting the value directly.

I'm assigning to sebsg@ because he's owned changes in this area. It's unclear how to address this without significantly impacting the usefulness of this feature. I'm interested in hearing people's thoughts.
1.9 MB Download

Comment 3 by, Jan 17 2018

Thanks Math, I'll update this with some ideas soon. In then meantime I just want to re-emphasis that Credit Card and Address Autofill work a bit differently than Passwords:

For Addresses and Cards, the user needs to either double click on a field or start typing for them to get the Autofill popup containing suggestions. Then only when they hover their mouse over the suggestion do we preview these in the fields (ShadowDOM). Then when they click on the suggestion we fill the values in the fields.

For Passwords, the values are previewed (ShadowDOM) on page load and are filled in the fields when a user gesture is detected.

Comment 4 by, Jan 17 2018

Forgot to mention that Passwords can also be triggered the same way Addresses and Cards too, in addition to the page load behavior.

Comment 5 by, Jan 17 2018


Comment 6 by, Jan 17 2018

Is this a duplicate of 798492, or should we keep them separate (possibly closing 798492)?

Comment 7 by, Jan 17 2018

Components: Privacy
Labels: Team-Security-UX OS-Fuchsia OS-iOS

Comment 8 by, Jan 17 2018

Re #6: I don't think this is dupe of 798492, insofar as it is broader (applies to autofill which is perhaps surprisingly different than password manager) and the mitigations may well be different.

Comment 9 by, Jan 17 2018

> It's unclear how to address this without significantly impacting the usefulness of this feature. I'm interested in hearing people's thoughts.

The usefulness of this feature here means that the user can preview all the data before selecting it? Maybe UX has some ideas. I could imagine, say, a flyout on hover that shows the data without sending it to the renderer.

Comment 10 by, Jan 17 2018

My comment 798492#30 was a proposal to dupe that into this one.

What's unclear to me is the implications of mitigation we see coming these days (kernels being patched, hires timers being coarsened, ...). Do we need to fall back to fill-on-account-select, which I would definitely consider a big usability loss?

Comment 11 by, Jan 17 2018

My take: we generally need to assume any data in the renderer process is accessible to JavaScript on a page.  V8 mitigations for Spectre will help make this less likely, but Spectre based attacks may still succeed and leak such data.

When Site Isolation is enabled, I don't think we need to be concerned about this particular threat for passwords, because we'll only send those to renderer processes dedicated to the corresponding site.  Issue 798492 covers a different threat than Spectre (i.e., third party scripts on a page trying to get access to those passwords), so let's not dupe that.

However, even with Site Isolation enabled, credit cards and addresses can end up autofilled into an attacker's process.  We should ensure that an attacker can't cause that data to be sent to the renderer without the user interacting with the form.

If comments 2-3 are correct, that may already be the case.  More specifically, it sounds like the user has to click on the form to get the browser process UI, and then hover over the suggestion before the data is sent to the renderer.  If that's accurate, I'm probably comfortable with it.

palmer@ had some additional concerns and was hoping for some consistency between how this data and passwords are handled, so I'll let him comment on whether anything is still needed here.

Comment 12 by, Jan 18 2018

creis -- What's your opinion on security-severity for this bug?

Comment 13 by, Jan 24 2018

Another ping for security-severity :) Should this be severity-low given that it relies on other bugs to be exploited?

Comment 14 by, Jan 24 2018

Labels: Security_Severity-Medium
My current understanding is that the risk described in this bug does not exist, because the non-password autofill data is already not sent to the renderer without a user gesture on the form.  That would imply we could probably close the bug.

I'm also not sure yet what our severity guidelines for Spectre attacks are.  Those technically do not require other bugs in Chrome for exploitation to succeed.  So if it were the case that the original report here was correct and the data was sent to the renderer, I'm guessing we would consider that a Medium.

palmer@: Can you confirm if we can close this, based on our discussions on Monday?  Or are there more things we should follow up on?

Comment 15 by, Jan 25 2018


1. When you click on the form, the menu that appears: is it chrome in the browser process, or generated by the renderer process?

2. Does the click on the form have to be a real user gesture, or can JavaScript synthesize it?

Testing with developer console on (e.g. ``), it seems like the answer to #2 is "has to be a real gesture". If that's correct, that's good.

Apologies if I've asked the same questions before; I never know which kind of autofill data is in question, and I've got a million other plates spinning right now...

Comment 16 by, Jan 25 2018

1. Browser process.

2. Correct, website can't bring it up.

Comment 17 by, Jan 25 2018

Status: WontFix (was: Assigned)
Thanks! In that case I agree with #14 that we can close the bug.

Comment 18 by, May 3 2018

Project Member
Labels: -Restrict-View-SecurityTeam allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot

Sign in to add a comment