なるほど。インテルのUSBコントローラ、ベンダーIDは8086なのか。（WebUSB API叩いてる
— Yosuke HASEGAWA (@hasegawayosuke) 2017年9月9日
WebUSB APIの接続許可ダイアログってこんな感じなんだけど、これで何のデバイスが接続許可を求めているのかきちんとわかる人いるのかな… pic.twitter.com/COnORHoUL6
— Yosuke HASEGAWA (@hasegawayosuke) 2017年9月9日
少なくともこのWindows VMにはNucamって文字列はレジストリ内には存在しない。何のデバイスなのか接続してベンダーID、プロダクトIDをデバッガで見てみるまでわからんっていう…。
— Yosuke HASEGAWA (@hasegawayosuke) 2017年9月9日
ああそうか、WebUSB APIは「その時点で挿さっていないUSBデバイスのふりをする」っていうのは無理で、その時点で存在するUSBデバイスとの対話しかできないので、USBキーボードが挿さっていないPCでBadUSB的なことをするのは難しいのか。
— Yosuke HASEGAWA (@hasegawayosuke) 2017年9月10日
とはいえVM上のWindowsではWebUSB APIからUSBコントローラは見えてるので、USBコントローラと直接しゃべることで何かしらできる可能性はある。Macでは何も指していない状態では全く何も見えない。
— Yosuke HASEGAWA (@hasegawayosuke) 2017年9月10日
"Tracking user with WebUSB API" なら今すぐできるな。
— Yosuke HASEGAWA (@hasegawayosuke) 2017年9月10日
WebUSB のヤバい仕様、これを Chrome がデフォルト有効にしたってのがもうね(ry(ry
— Tsukasa #01 (@a4lg) 2017年9月10日
BadUSBみたく「USBデバイス - キーボード - のふりをしてホストと適当にしゃべってキー操作する」はできない気がするな。とはいえおれのUSB力が低すぎていまいちわからん。
— Yosuke HASEGAWA (@hasegawayosuke) 2017年9月10日
デバイス依存な感じですね。特定の USB デバイスのファームウェアを書き換えたとして、どこまで自由にできるか。デバイスの全て (認識され方含め) を書き換えられるなら大問題で、かつ BadUSB の事例から考えると割とありそうという。
— Tsukasa #01 (@a4lg) 2017年9月10日
そうだろうと思います。とはいえそれは「そういうデバイスが挿さっていないと攻撃が成立しない」とも言えるので、なんとなく想像してた「悪意あるページ開いてうっかり許可した瞬間にUSB経由であらゆることができてしまう」みたいなのはなさそうだなと。
— Yosuke HASEGAWA (@hasegawayosuke) 2017年9月10日
刺さってるデバイス依存ではありますが、個人的には、割と手軽に列挙できちゃった時点で私としては非常に嫌な予感しかしないんですよねー。
— Tsukasa #01 (@a4lg) 2017年9月10日
WebUSB API、触れば触るほどよくこんなのブラウザに実装しようと思ったなという感想しか出てこないな。WebExtension APIでよかったやん。
— Yosuke HASEGAWA (@hasegawayosuke) 2017年9月10日
BadUSB 等の可能性について WebUSB 仕様書の "Attacking the Host" で書かれてるんですが…… https://t.co/kYVKynycZk デバイス製造者は署名された FW のみを……と。正直、それ WebUSB が言うべきことじゃないよね感。
— Tsukasa #01 (@a4lg) 2017年9月10日
うん、WebUSB 仕様書におけるこの警句、技術的には (technically) 正しいよ。ただ、技術的に正しいだけ。
— Tsukasa #01 (@a4lg) 2017年9月10日
えっと、元々 WebUSB は CORS 的な何かを想定していたらしいが、それ "でも" WebUSB はまだ危険足りうる (あり得る脆弱性によっては)。ただ気にするべきなのは WebUSB 対応デバイス+ドライバ製造者だけで、リスクはある程度コントロール可能だっただろう。
— Tsukasa #01 (@a4lg) 2017年9月10日
Chrome でデフォルト実装された WebUSB は、そういう慎重な書き方でコメントするに値しない。明らかにコントロール不能で、危険だ。
— Tsukasa #01 (@a4lg) 2017年9月10日
— 茂木 和洋 (@kzmogi) 2017年9月10日
コワイどころか危険なので、私としては無効化を広めていきたい所存。
— Tsukasa #01 (@a4lg) 2017年9月10日
正しい見解だと思います。問題は初期設定で、インストールorアップデートしたら有効で手動で無効化するまでそのまんまとかだと、他人にChromeススメられないな〜と。
— 茂木 和洋 (@kzmogi) 2017年9月10日
まぁ流石に許可ダイアログはあるんですが、個人的見解では、それが "ある" だけでは不十分。
— Tsukasa #01 (@a4lg) 2017年9月10日
"chrome://flags/#enable-webusb" で WebUSB の有効/無効を切り替えられます。私は迷わず Disabled (無効) に。WebUSB は危険な割に、許可ダイアログではその真のリスクが伝わりません。無効化を広めていきましょう。 pic.twitter.com/F54FQlwdIA
— Tsukasa #01 (@a4lg) 2017年9月10日
oO( ハッ……！もしかすると、WebUSB は Java よりはるかに安全な選択肢なのではないか？ [錯乱] )
— Tsukasa #01 (@a4lg) 2017年9月10日
WebUSB、この投げっぱなし感は確かにヤバいね。ヤバいファームウェアとかアップロードされたらヤバイので気を付けましょう・・・ですかw https://t.co/7GVONEqStm pic.twitter.com/RvrgP4BbNG
— Takashi Kawasaki (@espresso3389) 2017年9月9日
Resource ServerはAuthZ Serverが発行した正規のAccess Token以外を受け付けないように。というのと同レベルでは？
— nov matake (@nov) 2017年9月9日
デバイスメーカーのITリテラシーってクソ低いんですよ。ファームウェアに電子署名してるところなんて大手でもかなり限られるんじゃないかと・・・。チェックサムがいいところでしょう。
— Takashi Kawasaki (@espresso3389) 2017年9月9日
そういう人たちはWebUSB使うなよってことなのでは？
— nov matake (@nov) 2017年9月9日
横から失礼しますが……、今の WebUSB は初期コンセプトでは否定されていた、あらゆる USB デバイスがあらゆるサイトからアクセスできる状態なのです。WebUSB 仕様書が "あらゆる USB デバイスに" 配慮を求めてる形になってるので、何か違うって感じがします。
— Tsukasa #01 (@a4lg) 2017年9月10日
descripterてやつを公開してなくてもアクセスできるんですか...
— nov matake (@nov) 2017年9月10日
のです。……頭の痛い話です。
— Tsukasa #01 (@a4lg) 2017年9月10日
なるほど。そこは変わりそうですね。
— nov matake (@nov) 2017年9月10日
descripterを公開してないdeviceにアクセス可能なのは、web usbの仕様というかchrome実装の仕様ですか？
— nov matake (@nov) 2017年9月10日
WebUSB 仕様書が Chrome のようなお粗末な実装を禁止してないフシがあります。 https://t.co/ci8YTpBO7t "UA MAY use to...." またデバイス列挙については接続された全デバイスを列挙 "可能にしなければならない" と。
— Tsukasa #01 (@a4lg) 2017年9月10日
うーむ。僕はDiscoveryの仕組み用意してんだから、Discoverableになってない物は呼べないことを想定してるように読みましたが、Googlerが仕様書いて別のGooglerがコード書いたらこうなった、というのは、きっとそういう話はなかったのでしょうね。
— nov matake (@nov) 2017年9月10日
先日こんなふうに大量にWebUSBやばいぞ的なツイートが流れていた。実のところ私はさっぱり理解していない。とりあえずなんかdescriptorsが云々言っているので、規格書の該当箇所を見に行く。
WebUSB API#webusb-platform-capability-descriptor
§4. WebUSB Descriptors and Requests
This specification defines descriptors and commands the UA MAY use to gather information about the device specific to implementing this API.
§4.1. WebUSB Platform Capability Descriptor
A device announces support for the WebUSB command set by including the following Platform Descriptor in its Binary Object Store:
Offset Field Size Value Description 0 bLength 1 Number Size of this descriptor. Must be set to 24. 1 bDescriptorType 1 Constant DEVICE CAPABILITY descriptor type ([USB31] Table 9-6). 2 bDevCapabilityType 1 Constant PLATFORM capability type ([USB31] Table 9-14). 3 bReserved 1 Number This field is reserved and shall be set to zero. 4 PlatformCapabilityUUID 16 UUID Must be set to {3408b638-09a9-47a0-8bfd-a0768815b665}. 20 bcdVersion 2 BCD Protocol version supported. Must be set to 0x0100. 22 bVendorCode 1 Number bRequest value used for issuing WebUSB requests. 23 iLandingPage 1 Number URL descriptor index of the device's landing page.
bDescriptorTypeのことか？(全く無知なので間違ってたらすまん)
[USB31] Table 9-14を見てこいみたいなことを言っているので見に行く。
USB.org - DocumentsよりUniversal Serial Bus Revision 3.2 Specificationを落とす。103 MBもあるし通信速度が遅いが仕方ない。unzipしてUSB 3.2 Revision 1.0.pdfを見に行く。
§9.4 Standard Device Requests
This section describes the standard device requests defined for all devices. Table 9-4 outlines the standard device requests, while Table 9-5 and Table 9-6 give the standard request codes and descriptor types, respectively.
Devices shall respond to standard device requests, even if the device has not yet been assigned an address or has not been configured. If a standard request defines a persistent parameter that can be modified, the reset/default value for that parameter, unless otherwise specified, is zero.
Descriptor types are used to determine the type of descriptor being queried from a device or being set to a device. The existing standard descriptor types are listed in Table 9-6. All these values shall not be redefined and used in any USB class specification. In addition, this specification reserves the highest bit (Bit 7) of the descriptor type as a value that shall only be used by base USB specifications when defining new descriptor types .
Table 9-6. Descriptor Types
Descriptor Types Value DEVICE1 CONFIGURATION2 STRING3 INTERFACE4 ENDPOINT5 Reserved6 Reserved7 INTERFACE_POWER8 OTG9 DEBUG10 INTERFACE_ASSOCIATION11 BOS15 DEVICE CAPABILITY16 SUPERSPEED_USB_ENDPOINT_COMPANION48 SUPERSPEEDPLUS_ISOCHRONOUS_ENDPOINT_COMPANION49 The
INTERFACE_POWERdescriptor is defined in the current revision of the USB Interface Power Management Specification.
うん、全くわからん。
とにかく
まあdescriptorsがなくても列挙可能で認可を求めるChromeのUIにユーザーが判断するために必要と思われる情報が載っていないために、とりあえず無効にしとけ、という話でいいのか？
にアクセスして
をDisabledに。
Chromeを再起動すれば適応されます。
