WebGPU is more useful but direct access to hardware that could have coherent memory access/DMA is just irresponsible.
Chrome needs it for chromebooks. Not sure why it's needed for less constrained machines.
I'm nervous about justifying one thing based on the fact that a different, objectively terrible, thing is allowed already.
If we spam users with requests like that and lose control of simple things, there's no chance for us to ask a meaningful question about webusb. I've seen this on my mom's mobile phone. It's full of news notifications that annoy her - because she defaulted to clicking "allow", because she's a typical user.
Said code persists after reboot.
Please point out if this attack is not viable:
Ask for permission to use your keyboard. No matter how scary the warning, non-technical users will allow a website to use the keyboard because "of course it needs a keyboard"
Upload a malicious payload to keyboard. Remember, now it can present itself as any USB device. Or maybe stay simple with a keylogger, maybe with heuristics to get juicy data (what are the first 20 characters typed at boot and after "www" is typed)
Game over?
The upcoming WebHID API considers and mitigates this attack as well https://wicg.github.io/webhid/#introduction
(And yes I read the section 3 of the standard before writing the comment above, see my other comment in this thread)
WebHID even says it more plainly:
> In general, these types of attacks are device-specific and cannot be mitigated at the API level.
Both documents you linked literally go:
"We know these attacks exist, we don't care as long as we show a prompt, device manufacturers fix your shit it's not our problem"
-
I can't reply for some reason but:
I didn't see any mention of HID devices not being listed, not was it immediately apparent that a HID device would already be held in the kernel context
I also still don't see blocking input from trusted devices, I see the same language I called out:
"Device manufacturers should watch out"
-
"I think it works like this, why doesn't it" is a great way to learn things, except when the reply is a low effort: "here's that thing you read, did you actually read it?"
"Lastly, since USB devices are unable to distinguish requests from multiple sources, operating systems only allow a USB interface to have a single owning user-space or kernel-space driver. The UA acts as a user-space driver, therefore allowing only a single execution context to claim a USB interface at a time. The claimInterface() function will fail if multiple execution contexts attempt to claim an interface."
I.e. the keyboard couldn't be claimed even if you managed to get it to list as it's claimed via the OS HID driver so can't be claimed via the userspace driver. HID devices are also hid from the listing (no pun intendend) which is what resulted in the WebHID standard in the first place.
For WebHID understand it's an early draft and that the method described in section 3.1 of blocking access to HID devices that can generate trusted input is actually the go forward implementation plan not merely a suggestion.
.
I don't mind discussing WebUSB further but not if the conversation is just going to be in a "I thought it might work this way, show me the line that says it isn't" way. There are many blog posts that cover it better than I could anyways (such as https://blog.scottlogic.com/2019/04/03/upcoming-webhid-api.h...)
I didn't see any mention of HID devices not being listed, not was it immediately apparent that a HID device would already be held in the kernel context
I also still don't see blocking input from trusted devices, I see the same language I called out:
"Device manufacturers should watch out"
-
"I think it works like this, why doesn't it" is a great way to learn things, except when the reply is a low effort: "here's that thing you read, did you actually read it?"
Also I'm pretty sure the parent's point is jumping from "the kernel and userspace are not allowed to both access a device" to "keyboards cannot be accessed" is non-obvious
I still don't see where the filter on HID devices is mentioned, or the exception for trusted devices
It's not so much about the HID class itself as "why" (it's more an effect you find out later once you know what the HID class is) as it is "if an OS driver doesn't already hold the USB keyboard how could you type on it". The opening paragraph of the standard tips this off straight away:
"...Standard device classes include keyboard, mice, audio, video and storage devices. Operating systems support such devices using the "class driver" provided by the OS vendor..."
That combined with the closing paragraph of 3.1 under security considerations I quoted before led to the answer for the particular question without the explicit mention of "HID" in the document:
"Lastly, since USB devices are unable to distinguish requests from multiple sources, operating systems only allow a USB interface to have a single owning user-space or kernel-space driver. The UA acts as a user-space driver, therefore allowing only a single execution context to claim a USB interface at a time. The claimInterface() function will fail if multiple execution contexts attempt to claim an interface."
I later ran across "HID" reading a blog post while testing some code which is how I fumbled to finding WebHID. For the WebHID portion the hint I originally mentioned came from this paragraph in 3.1:
"In some cases, a device may expose functionality that should not be accessible at all from a web page. Specific devices may be blocked by recognizing the device by its vendor and product ID and hiding such devices during enumeration. The HID report descriptor allows a device to describe its own capabilities, and this information can be used to block classes of devices even when the vendor and product ID cannot be known in advance. This can be accomplished by inspecting the usage values assigned to collections within the report descriptor; for instance, access to keyboard-like devices can be denied by denying access to devices that include a top-level collection with the Keyboard usage ID."
I guess "mitigates" wasn't fair as the feature still hasn't even had an experimental implementation added behind a flag in Chrome yet let alone have a demonstrable implementation of the proposed protection. I'd say "considered" was fair though and not at all hidden/hard to find.
I also wanted to point out that the wording around "manufacturers should do" in both is presented an argument for defense in depth (IIRC they even called out defense in depth explicit in one of the calls to action) not their argument for "since manufacturers should do this we shouldn't do anything". Again about reading to find "why" vs "why not" which usually requires reading in context instead of searching for a key phrase.
.
Don't get me wrong, questions are a fine method of learning! It's just your initial question was "Please point out if this attack is not viable" not an ask of "I saw this in the standard, can you explain why this attack is not viable?" so I told you it's not viable and then mentioned it's in the first 3 sections in case you were curious. The response I got back was that you had already read section 3 and got a different takeaway. Well of course you did, I didn't say why was in section 3 I said it was in the first 3 sections, which are quicker reads than the comment chain the question came from! Going on good faith I pulled the exact quote out, explained it further, and then mentioned "I thought it might work this way, show me the line that says it isn't" isn't how I want to talk about the standard to then get told my original comment which answered exactly what you asked was low effort! Looking back I can see the confusion with section 3/first 3 sections and that originally you very likely meant "could you explain why" not a literal "is it or not" so my apologies for misinterpreting where you were trying to drive the conversation but I ask you consider the above as well before judging my reply/cautiousness to be just low effort/dismissive.
Anyways I hope the content above the "." gets us on the same page. I'd have shared some modified WICG/webusb GitHub repo linked demos I worked on earlier to validate my understanding before I said "nope" but they don't work on JSFiddle/CodePen because WebUSB requires a feature-policy header to be set to be used in a page + "allow" to an iframe (which seems like other great protections but absolute pains for testing!) so you'll just have to take my word on the real world test :).
Have you reported the issue to the maker?
Has the responsible disclosure window elapsed?
Than will pick up on "this website wants to use your keyboard"
Your tech illiterate users fall for the former, but many people with just average technical knowledge would fall for the latter.
"This website uses your keyboard directly to secure your password, press yes when presented with the dialog"
Maybe give feedback here? https://github.com/WICG/webusb/issues/
"We identified the biggest security problem with this, but to get adoption we're going to rely on prompts (which we all know users pay attention to)"
Then the next section is:
"We know how the previous shortcomings can be exploited to pwn the host too, hosts, don't let yourselves get pwn'd k thnx"
What feedback is there to give, they know what's wrong, they just don't care.
If they have a way of truly sandboxing malicious uses, without entering into permissions request overload (no human is infallible), I'd love to hear it.
the "discussed at X f2f" is not filling me with confidence.
"Greetings, Rando Middle Manager. Your cousin Larry has been arrested by police in Elbonia. Please to pay US$500,000 into this Bitcoin account to free hime. Or if you do not have funds, plug in company secure USB drive and click OK."