Hacker News Reader

Comment by nailer | Hacker News Reader

The same logic could be applied to local software, which inevitably is also remote in origin.

At least browsers generally have a better permission model than desktop apps: "do you want to allow this web page for access to USB devices?".

View on HN

I am not sure I agree "browsers generally have a better permission model than desktop apps". Yes, browsers ask the user if they would like to allow, but do desktops apps have rampant XSS vulnerabilities? If you allow a site to use USB, you have to be worried that any XSS vulnerability will compromise your USB devices.

Weirdly enough I was talking a couple of days ago about requiring things like CSP (which would go very far in defeating XSS) for stuff like webcrypto and other sensitive bits of HTML5.

Someone working for one of the major browsers mentioned they'd considered it but decided against it - not sure on the reasons why but if they're reading this they might like to elucidate...

That would be a good first step. It would have to be a subset of CSP. Don't allow inline scripts or eval.. Only on https is another step I see as very important.

One reason might be that developers would probably just do the minimum possible CSP rather than following the spirit of it. Unlike with HTTPS, a CSP could be created with the exact same security model as no CSP using directives like unsafe-eval.

Like buffer overflow or bash injection?

I am not sure what you are getting at. Those don't occur on the web and are not an issue with desktop apps you install. If a desktop app wants to run a bash command, it can do it. It doesn't need to find a bash injection.

There isn't easily exploitable issues like XSS on the desktop. Meaning, if you run a desktop app you generally don't have to worry that some rogue code is injected into the app, unless the developers keys are stolen which is rare.

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.

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.

> At least browsers generally have a better permission model than desktop apps

The flaw with that is desktop apps have the ultimate permission model, you choose to have them, and don't just stumble across them.

How are users supposed to know whether they can trust a desktop app with near-unlimited access to their computer? Generally they don't, but blindly install it anyway because it seems to do something they need.

Yes, that's called "opt in" and it's the same security model this standard is proposing.

And your local apps don't self-modify the code all the time, whereas that's exactly what the dynamic browser environment with 3rd-party scripting is.

Do they, though?

I just tested this on the phone today - it sees even my damn ambient light, in real-time. Why the hell is stuff like this allowed to be seen by default in a browser?

http://webkay.robinlinus.com/

That website is not using specific browser features to find other devices. It is using standard JavaScript networking functions to check for known classes of devices on your internal network.

Might be splitting hairs, but it's not like the browser is providing a direct API to that data.

> The same logic could be applied to local software, which inevitably is also remote in origin.

One big difference is that one chooses to download the software and install it on a computer. In a browser, everything gets downloaded and executed automatically, including scripts. It's just a matter of opening or being redirected to a URL.

For the average user the two concepts are not so different. Most people wouldn't think twice about downloading an executable, just like they wouldn't think twice about clicking a link.

Which is why it's even more dangerous to browse the web with all receptors (features) enabled.

Add preloading of links on pages, and you have yourself a constant modifying environment (browser) which is controlled by third parties that don't first require a permission dialog.

So, this is much unsafer than consciously running an executable you've downloaded.

You have to give it permission to use USB, though. The USB functionality might also be something included in software you downloaded for another purpose, without your knowledge.

The sensible alternative is to not enable this functionality at all. USB security is a joke, the risks for this API are too high.

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

Local peripherals won't be exposed unless they specific declare they support WebUSB.

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.

https://msdn.microsoft.com/en-gb/library/windows/hardware/hh...

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

With or without WebUSB, browsers can already talk to USB devices, and so if you can exploit the browser to run your own code, you can too.

Then show me the USB interface code in firefox. As far as I know, it doesn't exist.

It's in the Win32 DLLs that Firefox links against.

Reply on news.ycombinator.com