Hacker News Reader

Comment by ZenoArrow | Hacker News Reader

Exactly. Combine a XSS attack with USB keyboard monitoring and you've got ridiculously powerful password harvesting. That's just one potential attack of many.

View on HN

That's not at all an accurate framing. I'm not aware of any implementation that plans to allow access to HID devices (keyboard, mouse, etc.) or other device classes that are already handled natively by the browser/OS. Even ignoring security, just think of what a mess the user experience would be if sites could unbind and override native devices.

Implementations are always perfect?

When - not if - someone finds an implementation bug in either the browser or the USB hardware, we will see exploits far worse than keylogging passwords. The bug could be in any USB device, not just the subset you're thinking about. Do you really want to trust your host-controller, every USB device, and the browser interface to be bug free? Are you sure there are no subtle non-bug interactions between devices? Have you even seen how USB devices are designed?

Limitations like "no HID devices" are how it's supposed to work, which is different from how it will actually work.

edit:

Also, did everyone forget about BadUSB?

Sorry, but I'm at a loss for what you believe you're responding to here. I made a clear, factual statement regarding the handling of bound USB devices for known devices and classes. Specifically, HID and other native device classes that are already bound by the OS should not be exposed to WebUSB -- the reasons for and robustness of that guarantee should be self-evident to anyone moderately familiar with USB in modern OSes.

Now, if you have a specific argument to make against my statement, then please share it. I have direct experience with the subject here, and ideally can provide context to address such arguments or clear up confusion. However, I really don't think it's productive to respond with non sequitur arguments and personal attacks.

The way USB devices work, they can pretend to be something else and still manage to achieve the ulterior goal. There are some very interesting USB devices on the market which look like one thing, pretend to be something else, and actually are anything but.

Mentioning BadUSB very much implies confusion about the threat models at play. That is, the threat model for BadUSB is a malicious device that attacks the host OS, drivers, or applications. Whereas, the threat model for WebUSB is concerned with malicious sites attacking or abusing physical devices attached to the system.

So, the scenario you seem to be implying would require coordination between a malicious WebUSB site and a malicious device. While I can't claim that it would be impossible, it sure seems to approach de minimis if only given the extent of user interactions and preconditions.

You could say all the same things about every piece of desktop software.

So we're limiting based on USB device type are we? What about USB keyboards with USB ports in them (which are fairly common). They could be registered as USB hubs. One of the main reasons USB security is so poor is that the barriers between device types are not strictly enforced, which has led to problems in the past (for example, USB device spoofing is trivial to do, you can probably imagine the sort of hijinks you can get up to with that).

Sorry, you seem to have misread my statement. Everything you just listed are devices that the OS already natively binds. I'm not aware of anyone considering WebUSB implementations that would unbind native devices and expose them to the Web. Rather, the device-level risks for WebUSB primarily center around devices/interfaces that are not in well-known classes or otherwise are not natively bound and may expose dangerous interfaces (e.g. security credentials, unsigned firmware flashing, etc.).

Every USB device that the browser has access to will have a driver that the OS uses to expose its functionality. It doesn't matter whether that driver is built into the OS or not, the OS driver would still exist. The only other option is if the browser is managing hardware outside of the control of the OS by running with lower level privileges, but that opens up an even bigger security risk.

You suggested in another comment that you had some prior background in this area, are you involved in the development of this new web API?

> You suggested in another comment that you had some prior background in this area, are you involved in the development of this new web API?

Justin Schuh is a Chrome security engineer and is one of the most knowledgeable people on the planet when it comes to browser security. He knows what he's talking about more than virtually anyone else in this thread.

I'm not saying I disagree, but this reeks of argument from authority. Plenty of knowledgeable people make mistakes—because they're all fallible.

This is not argument from authority. You're free to believe that Justin Schuh is a fraud, or a moron, or just plain wrong in this one instance, but when a person who is an expert in a subject makes a statement that is pertinent to that subject, that is merely called "expertise".

This response just doesn't make sense given that modern OSes expose USB through much higher-level device management and communication APIs. Those are the APIs browsers use, and I've already explained that browsers shouldn't unbind and then expose a device that the OS or another native application has already bound. So, I really don't understand what argument you're trying to make here.

Reply on news.ycombinator.com