|Security: Autocomplete data can be stolen by malicious webpage|
|Reported by stoned...@gmail.com, Aug 9||Back to list|
VULNERABILITY DETAILS Chrome autocomplete data (e.g. email addresses) can be stolen by a malicious webpage, if the page can convince the user to hold down the 'up' or 'down' arrow key for a few seconds (maybe by playing a game). This works even in Incognito mode. Pressing the up/down arrow key in a form field causes the autocomplete popup to appear. Pressing the key again causes entries to be selected and the value to appear in the form field. This is done using Shadow DOM, so the value shouldn't be accessible until the user actually chooses a value (e.g. by hitting enter or clicking it). However, doing setSelectionRange(0,0) to clear the selection, followed by execCommand('insertText', null, ' ') causes the the shadow DOM value to be modified and placed into the .value field of the input. The autocomplete popup can be moved by changing the position of the input field. I've had limited success with moving it offscreen. On Ubuntu it seems be fully hidden if the browser is not maximised. On Windows it sometimes partially renders if the browser is not maximised. VERSION Chrome Version: 62.0.3179.0 (Canary) Operating System: Windows 10, Ubuntu 16.04 REPRODUCTION CASE Open the attached file and hold down either the 'up' or 'down' arrow key (you can also just tap the key repeatedly). If you have email addresses in your autocomplete data, they should be shown on the page. If you click the hide button first, the page will attempt to hide the autocomplete popup. As I mentioned above this seems to work in incognito mode.
I've also put the PoC at http://dev.jigawatt.co.uk/dev/autocomplete/steal.html
Here's a version that grabs credit card details across multiple fields (also works in Incognito). You could probably also grab address data like this too.
Here's a form for saving test credit card data if you need it.
And hosted PoCs if you want (obvs don't use real card data!): https://www.stonie.co.uk/autocomplete/cardsteal.html https://www.stonie.co.uk/autocomplete/cards.html
felt, can you suggest someone on your autofill team to take a look at this?
estark is the Enamel TL. It sounds like we need to fill the form fields not on arrow (or mouseover), but on *select* (Enter or click).
re comment#8: It sounds like that is generally the behavior, but the PoC gets around it with the following lines, to cause the value to populate into the normal DOM: field.setSelectionRange(0,0); var result = document.execCommand('insertText', false, ' ');
A more appropriate title for this bug might be 'Autocomplete data can be stolen via Shadow DOM leak'. I'm not sure if there are other places where sensitive data is held inside text fields using Shadow DOM - but if so, they would be vulnerable too. I think another difference from issue 448539 is that lots of data can be stolen fairly rapidly with a single user gesture. Without this bug, an attacker would have to convince a user to type 'down, down, enter', then 'down, down, down, enter' and so on.
Hi Roger, can you have a look at this?
rogerm: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers? If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one? If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Seb, I'm OOO with no computer for another week, do you have some cycles to look at this? If not, I can look at it once I'm back from vacation. There's another bug about chrome failing to fill shadow dom elements, which is an interesting twist on this.
I digged into the code to "preview" autofill suggestions and I arrived at this: The SetSuggestedValue of the HTMLInputElement class in WebKit (link at the bottom). tkent@ are you familiar with this part of the code? I would appreciate any pointers you might have. Thanks! * https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/HTMLInputElement.cpp?sq=package:chromium&dr=CSs&l=1063
Autofill team added the concept of 'suggested value' to HTMLInputElement, and I'm not so familiar with it. Probably, we should disabled all of editing operations to a text field while it has a suggested value. Or we should show autofill preview values as 'placeholder' text instead of a kind of 'value'. +yosin, who is an editing expert.
Thanks tkent@! yosin@ can you please advise when you can? Thanks
You can also "repro" the bug manually. Steps: - Preview an autofill value in a field (ex https://rsolomakhin.github.io/autofill/) - Use the left arrow key to put the cursor on the left of the input field. - Press the "space" key, or any other. In this case the action is taken by the user, so it makes sense to set the field's value. The bug is triggering the same behavior programmatically.
Here are some updates of my investigation: When an Autofill suggestion is previewed/suggestion, it is selected entirely in the originating field. By changing the selection range (field.setSelectionRange(0,0);), the previewed value becomes unselected and thus will not be overwritten if the user types. Then when the space is inserted (document.execCommand('insertText', false, ' ');), InsertTextCommand::DoApply(*1) is called. What is surprising there is that the space is inserted in the previewed value. Then, since this is a change that originates from the user side (vs browser side) this new value is set as the field's value, thus it is accessible in the DOM. I am really surprised that when the space is inserted, it gets inserted in the suggested value. It seems like the data_ attribute of the Text object(*2) contains the suggested value of the field. *1: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/editing/commands/InsertTextCommand.cpp?dr=CSs&q=inserttextcommand&sq=package:chromium&l=255 *2: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/CharacterData.cpp?type=cs&sq=package:chromium&l=93
TL;DR: To preview suggested value like placehold == do not hold suggested value in inner editor I suggest to introduce suggested value element in shadow DOM tree like placeholder. The content in inner editor of text control is exposed scripts and scripts can access someway, e.g. execCommand, copy to clipboard.
After some investigation I don't think I could realistically make a good change guaranteed to be correct in time for M-62 (including the merge window) Do you think you guys could take it on?
This is definitely a candidate for merge post branch. Yosin, let us know if this is something you can tackle quickly. Thanks!
Addition to #c22, the element for suggested value in UA shadow tree is used only for previewing value. Once user commits, by user action, previewed suggested value should be copied into inner editor. #c23, Do you think you guys could take it on? No, we don't have enough bandwidth. Since it seems the change is not small, == too short for canary testing, fix should be in M-63.
I disagree about M63 timeline. This is pretty serious as it exposes credit cards without user consent. We should be aggressive about merge ASAP.
+! to comment 26. We should get a fix landed ASAP and then evaluate the feasibility of a merge; we shouldn't delay a fix on the assumption that it won't be mergeable.
It's being actively worked on by sebsg@ for M62.
*** Boilerplate reminders! *** Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an eligible charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing. *********************************
Nice one! The VRP panel has rewarded $1,000 for this. Also, how would you like to be credited in release notes? Cheers!
Thanks! Could you credit me as: Paul Stone of Context Information Security
This bug requires manual review: Reverts referenced in bugdroid comments after merge request. Please contact the milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
I don't know why the merge request was added, it should have landed in M-64 initially.
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|