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.

The same trick works for web-bluetooth, please see the attached poc.

Deleted: webbt-perm-poc.html 508 bytes

webbt-perm-poc.html 508 bytes View Download

reillyg: Can you please route this to a likely fixer? Thanks.

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.

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.

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

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.

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.

Deleted: paired.png 12.0 KB

	paired.png 12.0 KB View Download

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

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

Deleted: poc-webusb.html 438 bytes

poc-webusb.html 438 bytes View Download

Deleted: poc-webbt.html 485 bytes

poc-webbt.html 485 bytes View Download

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.

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?

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

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.

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

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

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

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

The fix should be in 69.0.3472.3 and later.

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

The change above is already on the M-69 branch.

*** 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.
*********************************

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?

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

Thank you for verifying.

*** 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.
*********************************

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