> The sensible alternative is to not enable this functionality at all.
Far too many people seem to think the solution to security problems to ignore security and only consider the features you want.
This is such a bad idea that I'm starting to question the motives behind it. If I wanted to break the security of an important class of software, it would look something like this "standard".
> USB security is a joke
Most hardware security - USB or otherwise - doesn't exist. Local peripherals were never designed with security in mind.
In order for this to be even vaguely secure, every single device that declares support for WebUSB has to refrain from allowing firmware updates over WebUSB despite how incredibly convenient this is, and despite how much of a support nightmare it would be to roll out bugfixes to users without it, and despite them being developed by hardware manufacturers who generally don't give a fuck about security. I can't see this happening. (Allowing remote firmware updates effectively gives full remote code execution on the host PC to the website behind the device, since it can then emulate USB input devices.)
Oh, I don't disagree; I would bet some of those devices will get owned. My only hope is that the manufacturers will set the "origin allowed" field that says what domains may access the devices.
To see all potential security issues, you need to look at the whole tech stack. A single USB device can have multiple drivers, and although only one is active at any given time the decision over which one to use can be influenced by applications.
"A USB configuration defines the capabilities and features of a device, mainly its power capabilities and interfaces. The device can have multiple configurations, but only one is active at a time. The active configuration isn't chosen by the USB driver stack, but might be initiated by an application, a driver, the device driver. The device driver selects an active configuration.
A configuration can have one or more USB interfaces that define the functionality of the device. Typically, there is a one-to-one correlation between a function and an interface. However, certain devices expose multiple interfaces related to one function."
So let's say I want to exploit this new WebUSB API. If I infect your computer with malware that installs a second USB driver for the hardware I want access to, and this second driver has support for WebUSB, I could theoretically control the driver being used by making a WebUSB request for the device, thereby exposing the hardware for further exploits.
This is what Raymond Chen calls "being on the other side of the airtight hatchway". If you can install an USB driver on my machine, it's because you can run native code on my machine, and so you can use that to talk to the USB device without requiring WebUSB.
The difference between using the malware itself to communicate via the web and using WebUSB to do so would be in malware detection. If an unidentified EXE hidden in your Windows partition is communicating via the web that's going to look a lot more suspect than a driver which is trusted by the system. The malware that installed the driver could remove itself after installing the driver, taking out another way to track it down.
An unidentified process talking to the 'net is more suspicious than one installing drivers?
But fine, let's say the malware installs the driver and deletes itself. What then? How are they going to get the browser to navigate to their site, and the user to click the authorization button?
> "But fine, let's say the malware installs the driver and deletes itself. What then? How are they going to get the browser to navigate to their site, and the user to click the authorization button?"
You could do it a number of different ways. For example, could edit the hosts file (a.k.a. etc/hosts) to point to an amended site for a popular website address, could configure proxy settings on default web browser, could alter the browser shortcut to run a script in the background when the browser starts that scans for WebUSB-enabled devices, could set the driver up to check for updates and disguise the authorisation as the driver update confirmation, etc...
So this antivirus lets the malware install drivers, edit system files and/or replace shortcuts created by other applications, but not talk to the web, when nowadays almost every program connects to the web to check for updates. Do you know how far-fetched that sounds?
The reality is that if this malware gets enough permissions to install drivers, it can certainly talk to a regular device driver and communicate with the web. It doesn't need WebUSB for anything.
Do you really think attackers will respect that limitation after they overflow a buffer in the browser? You're only looking at how it's supposed to work. What matters is how it will be exploited.
