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
Owner:
OOO until 30 July
Closed: Jan 25
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , iOS , Chrome , Mac , Fuchsia
Pri: 2
Type: Bug-Security



Sign in to add a comment

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

Project Member Reported by creis@chromium.org, Jan 17

Issue description

VULNERABILITY DETAILS

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.

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

 
Components: UI>Browser>Passwords
Cc: rogerm@chromium.org durgapandey@chromium.org
Labels: -Pri-1 Pri-2
Owner: se...@chromium.org
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.


datapreview.mov
1.9 MB Download
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.
Forgot to mention that Passwords can also be triggered the same way Addresses and Cards too, in addition to the page load behavior.
Cc: ma...@chromium.org
Is this a duplicate of 798492, or should we keep them separate (possibly closing 798492)?
Cc: awhalley@chromium.org msramek@chromium.org est...@chromium.org
Components: Privacy
Labels: Team-Security-UX OS-Fuchsia OS-iOS
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.
> 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.
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?
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.
creis -- What's your opinion on security-severity for this bug?
Another ping for security-severity :) Should this be severity-low given that it relies on other bugs to be exploited?
Labels: Security_Severity-Medium
Owner: palmer@chromium.org
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?
Questions:

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 https://rsolomakhin.github.io/autofill/ (e.g. `profile_autofill_name.click()`), 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...
1. Browser process.

2. Correct, website can't bring it up.
Status: WontFix (was: Assigned)
Thanks! In that case I agree with #14 that we can close the bug.
Project Member

Comment 18 by sheriffbot@chromium.org, May 3

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

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment