Issue metadata
Sign in to add a comment
|
Security: U2F device usable even when Chrome is a background window
Reported by
pete...@dropbox.com,
Apr 11 2016
|
||||||||||||||||||||||
Issue descriptionVULNERABILITY DETAILS When a website is waiting for the user to touch their U2F device, the U2F device remains functional even when the website is in a background tab, or when Chrome is not the currently active window. This could lead to the user mistakenly authorizing any website currently open in Chrome if they attempt to use their U2F device for another task, such one-time-password generation. VERSION Chrome Version: [49.0.2623.110] + [stable, beta, or dev] Operating System: [4.2.0-35-generic, Ubuntu wily] REPRODUCTION CASE See description above: navigate to a webpage that makes a U2F authorization request, switch to another active window, and then touch the U2F device. FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION Type of crash: [tab, browser, etc.] Crash State: [see link above: stack trace, registers, exception record] Client ID (if relevant): [see link above]
,
Apr 12 2016
,
Apr 12 2016
,
Apr 12 2016
@arnarb - could you take a look at this or suggest a different owner if appropriate? thanks.
,
Apr 12 2016
@juanlang, can you take this?
,
Apr 13 2016
Hi Peter, thank you very much for the report. I'm not sure I agree there is a Chrome issue here. There's a security risk inherent in U2F transaction, which is transaction confusion. The user cannot know what precisely she is authorizing when she confirms a transaction on a key handle, because the U2F protocol and U2F devices do not provide for trusted displays. This issue is present whether the request is coming from a foreground tab, a background one, an iframe or the top-level frame. Together, Chrome and the U2F authenticator still ensure that an assertion is only given to a relying party for its own keys. This is similar to how e.g. an embedded iframe or a background frame loaded from a.com will send a.com's cookies to a.com. In both cases, the same-origin policy ensures this data isn't shared with other domains in other frames. Further, even if the assertion were to be leaked from origin a.com to b.com, On the other hand, the U2F assertion is not replayable on any origin except its own: the signature is generated by keys registered only to a.com, and the value signed over includes both the challenge generated by the requesting origin, and the identity of the requesting origin. So, while there is user confusion possible, i.e. "Did I just approve a transaction for origin A, or origin B?" I'm not sure I would agree this constitutes an attack.
,
Jul 21 2016
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
,
Oct 1 2016
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
,
Oct 2 2016
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
,
Oct 2 2016
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by pete...@dropbox.com
, Apr 12 20161.1 MB
1.1 MB Download