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 4 users

Issue metadata

Status: Verified
Owner:
Closed: Jul 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 1
Type: Bug-Security



Sign in to add a comment
link

Issue 723503: Security: Mismatched Origin Display in WebUSB and WebBluetooth Permissions Dialogs

Reported by vervier...@gmail.com, May 17 2017

Issue description

VULNERABILITY DETAILS
A race condition exists allowing a malicious origin to display a WebUSB permission request in context of an arbitrary origin such as for example https://google.com.

Successful exploitation requires chrome://flags/#enable-experimental-web-platform-features to be enabled.
It also requires user interaction.
The origin requesting permissions is displayed in the permissions box.

We still see this as security relevant because the permissions dialog is visually connected to the origin and for average users it will be hard to notice that the origin does not match the permissions request origin.

VERSION
Chrome Version: 58.0.3029.110 (64-bit) stable
Operating System: Windows 10 Build 14393.rs1_release_sec.170427-1353

REPRODUCTION CASE
Attached are three files:

 - webusb-perm-poc.html - reproduction showing the WebUSB permission dialog  being displayed on https://www.google.com
 - webusb-permission-ui-confusion-1.jpg: Malicous site with a link to google.com
 - webusb-permission-ui-confusion-2.jpg: Popup being displayed on google.com, but the request is for a different origin
 
webusb-permission-ui-confusion-1.jpg
101 KB View Download
webusb-permission-ui-confusion-2.jpg
188 KB View Download
webusb-perm-poc.html
456 bytes View Download

Comment 1 by vervier...@gmail.com, May 17 2017

Addition: The race condition is between the change of location (and origin) and the display of the permissions dialog. A location change should trigger the permissions dialog to disappear, but the dialog stays.

Comment 2 by vervier...@gmail.com, May 17 2017

The same trick works for web-bluetooth, please see the attached poc.
webbt-perm-poc.html
508 bytes View Download

Comment 3 by elawrence@chromium.org, May 17 2017

Components: UI>Browser>Permissions>Prompts

Comment 4 by palmer@chromium.org, May 17 2017

Cc: lgar...@chromium.org est...@chromium.org reillyg@chromium.org jyasskin@chromium.org
Components: Blink>Bluetooth Blink>USB
Labels: M-60 Security_Severity-Medium Security_Impact-Stable Team-Security-UX OS-Chrome OS-Linux OS-Mac OS-Windows Pri-1
Owner: reillyg@chromium.org
Status: Assigned (was: Unconfirmed)
reillyg: Can you please route this to a likely fixer? Thanks.

Comment 5 by palmer@chromium.org, May 17 2017

Summary: Security: Mismatched Origin Display in WebUSB and WebBluetooth Permissions Dialogs (was: Security: UI Related Race Condition Regarding WebUSB Permissions Dialog)

Comment 6 by reillyg@chromium.org, May 17 2017

Labels: -OS-Linux -OS-Chrome -OS-Mac
Mergedinto: 624700
Status: Duplicate (was: Assigned)
This is a duplicate of issue 624700 and is only reproducible on Windows. The cause is a bug in Views on Windows which causes the request to dismiss the dialog to be lost for an as yet unknown reason. Importantly, clicking "Connect" does not grant any permissions as the backend for the dialog has already been destroyed.

Comment 7 by vervier...@gmail.com, May 17 2017

I can also reproduce the bug on Linux using the PoC at on Linux Chromium version 58.0.3029.110 (64-bit).

Also he pairing request succeeds as can be seen when you click connect and repeat the PoC.

I tested using the PoC at: https://www.x41-dsec.de/034uwf/confuse-webusb-perms.html

Either this is not a duplicate but a different bug, or it affects also other platforms besides Windows.
I cannot see 624700 from this account so I can't really check.

Comment 8 by reillyg@chromium.org, May 17 2017

ChromeBubbleManager is what should be closing these bubbles on navigation and other operations. I could not reproduce on Linux and macOS but that may mean that the Views issue is a race condition. I was able to reproduce on Chrome OS with Chrome 59.0.3071.47.

https://cs.chromium.org/chromium/src/chrome/browser/ui/chrome_bubble_manager.cc

Comment 9 by vervier...@gmail.com, May 17 2017

Yes, it might be that the BubbleManager created after the navigation occured, or that it's attached to a separate frame. On Linux here there is actually a slight delay of some ms between the dialog showing and the navigation to the other domain, so maybe it's the latter. But I'm not that deep into the Chrome source to really know.

Comment 10 by palmer@chromium.org, May 17 2017

The attacker origin does actually seem to get to pair to the USB device in question. (See attached screenshot.)

Either this might not be an exact duplicate of issue 624700, or that issue should be tracked as a vulnerability, perhaps.
paired.png
12.0 KB View Download

Comment 11 by palmer@chromium.org, May 17 2017

Cc: palmer@chromium.org

Comment 12 by sheriffbot@chromium.org, Aug 24 2017

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 https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 13 by felix.sc...@gmail.com, May 31 2018

Hey,

I was able to reproduce this issue on Windows 10 and Linux (see exact versions below). I slightly adjusted the PoC above and attached them as it seems to work more consistent for me. Since WebUSB is turned on by default by now this works without enabling the chrome://flags/#enable-experimental-web-platform-features flag. The PoC for WebBluetooth still require the flag to be enabled.

As this is probably a race condition this does not work every time. However, I was able to reproduce this issue every time I executed the exploit right after a restart (chrome://restart). If I granted permission to a device it works again if I navigate back. If I click cancel it did not work again. It might require a fast and stable internet connection and decent hardware (tested on i5 and i7 cores). It might also be dependent on more currently unknown factors.

I could also reproduce that if a user connects a device to the attacker's origin in this dialog it will be paired. Permissions are also persistent over restarting Chrome/ium. I have not been able to test if a promise after requesting the device gets executed but I think this is not possible. This would lower the severity a bit as a victim has to visit the attacker's site twice.

Attack Scenario:
An attacker might use this in a social engineering scenario. To make it even less obvious that permissions are requested for a different origin one could use similar domain names by either buying a new domain similar to the target one or by using e.g. a self-hosted github.io site and as target github.com. An attacker could simply write an email / message to the victim while impersonating the target domain, stating that he / she gets <insert incentive here> if the victim would visit a link and connect their smartphone or Yubikey to it. After a user granted permission to his / her smartphone or Yubikey the victim (probably) has to visit the site a second time. After the victim visits the attacker's site again an attacker could compromise a connected smartphone via adb ( https://labs.mwrinfosecurity.com/blog/webusb/ ) or compromise a Yubikey-like hardware token as shown by Markus Vervier and Michele OrrĂ¹ at OffensiveCon ( https://www.offensivecon.org/speakers/2018/markus-and-michele.html ). Which hardware to compromise is only limited by the imagination and time of the attacker.


Successfully tested for the following versions:

Google Chrome	67.0.3396.62 (Official Build) (64-bit)
Revision	babbbb5b433370f9a7feeb9f98a57599ad1c4676-refs/branch-heads/3396@{#702}
OS	Linux
JavaScript	V8 6.7.288.42
User Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.62 Safari/537.36
Command Line	/opt/google/chrome/google-chrome --flag-switches-begin --flag-switches-end
Executable Path	/opt/google/chrome/google-chrome

---

Chromium	67.0.3396.62 (Official Build) Arch Linux (64-bit)
Revision	babbbb5b433370f9a7feeb9f98a57599ad1c4676-refs/branch-heads/3396@{#702}
OS	Linux
JavaScript	V8 6.7.288.42
Flash	29.0.0.171 /usr/lib/PepperFlash/libpepflashplayer.so
User Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.62 Safari/537.36
Command Line	/usr/lib/chromium/chromium --ppapi-flash-path=/usr/lib/PepperFlash/libpepflashplayer.so --ppapi-flash-version=29.0.0.171 --flag-switches-begin --disable-touch-adjustment --enable-devtools-experiments --enable-experimental-web-platform-features --enable-scroll-prediction --extension-content-verification=enforce --show-saved-copy=secondary --top-chrome-md=material-hybrid --touch-events=disabled --flag-switches-end
Executable Path	/usr/lib/chromium/chromium

---

Google Chrome	66.0.3359.181 (Offizieller Build) (64-Bit) (cohort: Stable)
Revision	a10b9cedb40738cb152f8148ddab4891df876959-refs/branch-heads/3359@{#828}
OS	Windows
JavaScript	V8 6.6.346.32
User Agent	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36
Command Line	"C:\Users\<redacted>\AppData\Local\Google\Chrome\Application\chrome.exe" --flag-switches-begin --flag-switches-end
Executable Path	C:\Users\<redacted>\AppData\Local\Google\Chrome\Application\chrome.exe
poc-webusb.html
438 bytes View Download
poc-webbt.html
485 bytes View Download

Comment 14 by reillyg@chromium.org, May 31 2018

Labels: -allpublic -M-60 M-66 Restrict-View-SecurityTeam OS-Linux
Status: Assigned (was: Duplicate)
Thanks for the update. It definitely raises the severity if contrary to comment #6 the permission is successfully granted. I will take another look at this.

Comment 15 by vervier...@gmail.com, May 31 2018

Hi, just to note in comment #7 it was also stated that the permission is successfully granted, I was of the impression the bug has been fixed, but maybe only the crash mentioned in the other ("duplicate") bug report?

Comment 16 by reillyg@chromium.org, May 31 2018

Cc: felix.sc...@gmail.com

Comment 17 by dominickn@chromium.org, May 31 2018

Cc: ortuno@chromium.org

Comment 18 by sheriffbot@chromium.org, Jun 1 2018

Project Member
Labels: -M-66 M-67

Comment 19 by est...@chromium.org, Jun 13 2018

Hey Reilly, did you have a chance to take another look at this?

Comment 20 by reillyg@chromium.org, Jun 13 2018

Status: Started (was: Assigned)
I'm working on adding a browser_test to exercise this PoC. I can't reproduce the issue locally but I have a few theories.

Comment 21 by bugdroid1@chromium.org, Jun 23 2018

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2c6ce192cb3fb7bfbc3f3f862926dcb65c3891b4

commit 2c6ce192cb3fb7bfbc3f3f862926dcb65c3891b4
Author: Reilly Grant <reillyg@chromium.org>
Date: Sat Jun 23 22:41:47 2018

Ensure device choosers are closed on navigation

The requestDevice() IPCs can race with navigation. This change ensures
that choosers are closed on navigation and adds browser tests to
exercise this for Web Bluetooth and WebUSB.

Bug:  723503 
Change-Id: I66760161220e17bd2be9309cca228d161fe76e9c
Reviewed-on: https://chromium-review.googlesource.com/1099961
Commit-Queue: Reilly Grant <reillyg@chromium.org>
Reviewed-by: Michael Wasserman <msw@chromium.org>
Reviewed-by: Jeffrey Yasskin <jyasskin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#569900}
[modify] https://crrev.com/2c6ce192cb3fb7bfbc3f3f862926dcb65c3891b4/chrome/browser/ui/bluetooth/bluetooth_chooser_desktop.cc
[modify] https://crrev.com/2c6ce192cb3fb7bfbc3f3f862926dcb65c3891b4/chrome/browser/ui/bluetooth/bluetooth_chooser_desktop.h
[modify] https://crrev.com/2c6ce192cb3fb7bfbc3f3f862926dcb65c3891b4/chrome/browser/ui/browser.cc
[modify] https://crrev.com/2c6ce192cb3fb7bfbc3f3f862926dcb65c3891b4/chrome/browser/usb/usb_browsertest.cc
[modify] https://crrev.com/2c6ce192cb3fb7bfbc3f3f862926dcb65c3891b4/chrome/browser/usb/usb_tab_helper.cc
[modify] https://crrev.com/2c6ce192cb3fb7bfbc3f3f862926dcb65c3891b4/chrome/browser/usb/usb_tab_helper.h
[modify] https://crrev.com/2c6ce192cb3fb7bfbc3f3f862926dcb65c3891b4/chrome/browser/web_bluetooth_browsertest.cc
[modify] https://crrev.com/2c6ce192cb3fb7bfbc3f3f862926dcb65c3891b4/components/bubble/bubble_manager.cc
[modify] https://crrev.com/2c6ce192cb3fb7bfbc3f3f862926dcb65c3891b4/components/bubble/bubble_manager.h
[modify] https://crrev.com/2c6ce192cb3fb7bfbc3f3f862926dcb65c3891b4/content/browser/bluetooth/web_bluetooth_service_impl.cc

Comment 22 by sheriffbot@chromium.org, Jul 25 2018

Project Member
Labels: -M-67 Target-68 M-68

Comment 23 by meacer@google.com, Jul 27 2018

Reilly: Is there remaining work here? Can this be closed?

Comment 24 by reillyg@chromium.org, Jul 27 2018

Status: Fixed (was: Started)
I think this can be closed. I had another patch which attempted to add additional browser_tests to make sure that we could always observe that the dialog was shown when it should be[1] but my methodology there was flawed and the tests were flaky. I would really appreciate it if Felix could try to reproduce this in their setup because I haven't been able to reproduce.

[1]: https://chromium-review.googlesource.com/c/chromium/src/+/1117577

Comment 25 by awhalley@google.com, Jul 28 2018

Labels: reward-topanel

Comment 26 by sheriffbot@chromium.org, Jul 28 2018

Project Member
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify

Comment 27 by felix.sc...@gmail.com, Jul 30 2018

Hey Reilly,

Is your patch included in the 68 release? I just did a quick check and it still worked for me with the provided PoC.

This is the version I tested:

Chromium	68.0.3440.75 (Official Build) Arch Linux (64-bit)
Revision	cf598d63a4f1b9e7cd14f2a8433276b196e3e07d-refs/branch-heads/3440@{#738}
OS	        Linux

Comment 28 by reillyg@chromium.org, Jul 30 2018

Labels: -Target-68 Target-69
The fix should be in 69.0.3472.3 and later.

Comment 29 by sheriffbot@chromium.org, Aug 3

Project Member
Labels: Merge-Request-69

Comment 30 by sheriffbot@chromium.org, Aug 3

Project Member
Labels: -Merge-Request-69 Merge-Review-69 Hotlist-Merge-Review
This bug requires manual review: M69 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop)

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

Comment 31 by reillyg@chromium.org, Aug 3

Labels: -Hotlist-Merge-Review -Merge-Review-69
The change above is already on the M-69 branch.

Comment 32 by awhalley@chromium.org, Aug 6

Labels: -reward-topanel reward-unpaid reward-500
*** 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.
*********************************

Comment 33 by awhalley@chromium.org, Aug 6

Cc: awhalley@chromium.org
Thanks for the report, vervierx41@! The VRP panel decided to award $500 for this. A member of our finance team will be in touch to arrange payment. Also, how would you like to appear on the Chrome release notes?

Comment 34 by awhalley@chromium.org, Aug 6

Labels: -reward-unpaid reward-inprocess

Comment 35 by awhalley@chromium.org, Aug 7

Labels: reward-topanel

Comment 36 by felix.sc...@gmail.com, Aug 7

Hey Reilly,

I was not able to trigger the race condition on Chrome 69 with payloads that worked in Chrome 68. Seems fixed indeed.

Cheers,
Felix

Comment 37 by reillyg@chromium.org, Aug 7

Status: Verified (was: Fixed)
Thank you for verifying.

Comment 38 by awhalley@chromium.org, Aug 16

Labels: -reward-topanel reward-unpaid
*** 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.
*********************************

Comment 39 by awhalley@chromium.org, Aug 16

Labels: -reward-unpaid

Comment 40 by awhalley@google.com, Aug 16

Labels: -M-68 M-69 Release-0-M69

Comment 41 by awhalley@chromium.org, Sep 4

Labels: CVE-2018-16079 CVE_description-missing

Comment 42 by sheriffbot@chromium.org, Nov 3

Project Member
Labels: -Restrict-View-SecurityNotify 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

Comment 43 by awhalley@chromium.org, Jan 4

Labels: -CVE_description-missing CVE_description-submitted

Sign in to add a comment