Apparently some people are trying to open up as much attack surface as possible.
If you're implementing this... please stop. This will cause serious problems. There is no reason whatsoever to allow remote access to USB devices.
If you're implementing this... please stop. This will cause serious problems. There is no reason whatsoever to allow remote access to USB devices.
Unless you want to connect your local USB device to some VM in the cloud. Which is the direct use case that came up when this came up in discussion with Reilly Grant when we were both at VMware. It comes up surprisingly often as a requested feature, as IT organizations get increasingly lazy/less funded/laid off and don't want to have to install clients or anything on local machines, just pop open a browser, point it at the VM and connect up the device.
Not that I'm advocating for this in any way... I thought it was pretty out there (along with WebMIDI), but hey, why not, the Web Browser is the One True Platform and everyone and their parent company and sister company has nearly quit doing native application development on any OS (as sad as that makes me).
Why should we build this functionality into the browser? Is it really that much more convenient than installing an app to run the proxy?
The use case you describe is sufficiently rare, that if you need it, downloading an app should not be a high cost to pay. If only 1% of browser users need this USB proxy, why expose an additional attack surface for the 99% who do not need it?
There could be something similar for USB, where there might not even be any "codecs" (drivers) included by default in browsers, but where there's a defined method of making USB devices available.
You'd still have to install a plugin for each device type that your browser doesn't natively understand, but standardization for how to make specific device types available to the browser would be much simpler. And there could be "rewriting proxy" drivers available for improved security which limits what requests that are possible, preventing most hardware exploits.
Although this might still be too much work for little gain.
Apparently it is, given how highly requested of a feature it is to have everything you could do with VMRC available through the web browser with no plugins or local software.
Again, I still don't think it's a good idea either, but I also don't like a lot of the crazy shit built into modern web browsers for maybe the 1% users, like the mentioned WebMIDI.
Sorta but that's not what this standard is proposing. It's proposing a way of accessing a USB device from a web browser. There isn't any remote access happening here (at least not directly though with this standard you could theoretically do that).
This is simply so web apps can get closer to native apps in functionality.
> There isn't any remote access
If you don't see the contradiction between these two statements, I don't know how to help you.
Stop thinking of what this is supposed to do; it's the failure cases that are the problem. Good security design involves concepts like compartmentalization and defense-in-depth. Finding a browser exploit shouldn't also grant low level access to the USB buss.
> This is simply so web apps can get closer to native apps in functionality.
That's a terrible idea. Blurring the lines between a webpage and a native app simply teaches people to treat webpages as if they were a local app, when the should be learning to treat anything form the network as potentially hostile. If you don't have a clean separation between the remote UI and the local UI, you're creating the perfect situation for phishing attacks.
Alternatively you could be more constructive and try to explain what your position here is because, as I'm reading this standard, I'm not seeing any remote access (it's all client-side). Granted, like I already mentioned, once access is granted you could use something like web sockets to make it accessible remotely but that's a very explicit thing a developer or malicious app has to do. Which, granted, is possible but the user also has to give it access to do such a thing which is no different than allowing camera access which already exists in a similar way.
If you want to argue that anything that can be coded to be accessed remotely is outright remote access then...well just about everything is remote access and it kinda loses its meaning.
> Stop thinking of what this is supposed to do; it's the failure cases that are the problem. Good security design involves concepts like compartmentalization and defense-in-depth. Finding a browser exploit shouldn't also grant low level access to the USB buss.
This shows me you didn't even read the standard. The standard OUTRIGHT says the same thing as you and outlines how their standard WOULD NOT grant low level access to the USB bus.
So why even bother commenting if you're not even going to read what's in the standard and comment, incorrectly, about it? This isn't really typical on Hacker News.
Anything that can be accessed client-side can be easily uploaded via XmlHttpRequest or whatever people use for that now. This is not a new concept.
> Granted, like I already mentioned, once access is granted you could use something like web sockets to make it accessible remotely but that's a very explicit thing a developer or malicious app has to do.
Hardly- user data is incredibly valuable and you can be sure that for many sites, if a page has access to USB info they will upload and track it. Presumably any foreign JS code imported (e.g. Google Analytics) can also access this data and include it in the information it tracks.
Correct but this standard is absolutely not "remote access to USB devices" as the parent suggested. If we're going to abstract the meaning of "remote" to anything that can be uploaded by something that can access it then it loses its meaning entirely.
The standard proposes nothing remote from the web to the browser; it's entirely between USB devices and the browser. Saying "allow remote access to USB devices" is entirely misleading hence my original comment.
> Hardly- user data is incredibly valuable and you can be sure that for many sites, if a page has access to USB info they will upload and track it. Presumably any foreign JS code imported (e.g. Google Analytics) can also access this data and include it in the information it tracks.
What's the "hardly" for? You and I don't seem to be disagreeing here.
That being said, I'm a little confused about your definition of "remote" access. If I have a jetty server with a remotely exploitable hole in it, someone who exploits that hole is depending on me running a local client, but I would still consider it a "remote" exploit. In the same vein, someone running a browser that I can compromise with purely code on external websites is still being "remotely exploited." The attack vector requires the client to visit a specific page or click a specific link, but I didn't have to walk up to their computer and insert a USB stick. That's what makes the attack a "remote" attack for me.
But if you read the linked specification you're not doing that. You're giving them access to an abstraction that is quite limited in what it can do. If you had direct access you could reflash firmware.
> If I have a jetty server with a remotely exploitable hole in it, someone who exploits that hole is depending on me running a local client, but I would still consider it a "remote" exploit.
Yes of course that's "remote". It requires network connections to access.
> In the same vein, someone running a browser that I can compromise with purely code on external websites is still being "remotely exploited." The attack vector requires the client to visit a specific page or click a specific link, but I didn't have to walk up to their computer and insert a USB stick. That's what makes the attack a "remote" attack for me.
That's not remote at all. That's entirely client based. The client just happens to load some sort of exploit on its own. If it was really remote you could push a script to the client using its network address.
The client functions the same with or without internet connectivity. The jetty server example does not.
When a browser gets a malicious advertisement or a user gets a malicious cross-site scripting attack, I consider that remote exploit. Yes, it required the client to do something (i.e. visit a malicious page), but there are plenty of things which you can do to create that state without much user interaction. If I might ask, what do you call attacks like these?
I agree though that my Jetty example wasn't a good one, I was just making the point that the exploit was still in client code (i.e. something running on the victim's machine).
Just because it's in a browser doesn't mean it's remote access. Javascript APIs can be accessed locally.
I don't know what you're imagining my computer works like, but I don't have a separation between local and remote UI. I have a separation between OS and application UI (e.g. the Windows Ctrl+Alt+Del dialogue) but everything else is untrustworthy, local or no. A local app can be executing untrusted logic "sourced from" the internet just as well as a remote app can. To say otherwise is to presume that all updates to all apps on your PC go through a third-party that verifies that they never add any remotely-accessible "extension points" that weren't there in previous updates. Obviously, this is not the case, even for the strictest corporate device-management release-engineering program.
Which sucks, obviously, but it's not surprising that there's an attempt to bring the web closer to parity with native, since it seems to be a more tractable problem than stoping what's happening to native platforms.
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?".
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...
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.
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?
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.
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 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.
The flaw with that is desktop apps have the ultimate permission model, you choose to have them, and don't just stumble across them.
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?
Might be splitting hairs, but it's not like the browser is providing a direct API to that data.
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.
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.
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.
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.
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...
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.
Seriously though, wired connections are out. Bluetooth is the thing.
EDIT: and the less said about pairing difficulties the better.
EDIT2: From the downvotes it seems that many people have had a radically different experience from mine, which is good, because mine has been awful.
HTCOne-Dell: 1MB file will transfer ~50% of the time, pairing took several tries.
HTCOne-MBP: complete no-go, doesn't even pair.
Nexus6-MBP: paired first try, works reliably at a blazing 100kb/s.
Nexus6-Dell: doesn't even pair.
Nexus6-Fitbit: takes minutes to download a day's activity over bluetooth classic, stalls out completely 50% of the time. BLE doesn't seem to work at all.
MBP-Fitbit: requires dongle, synced once, has had 100% failure rate ever since.
Dell-Fitbit: requires dongle, 100% failure rate.
All other bazillion USB devices ever made are not designed to deal with security, and exposing them over the internet will blow up spectacularly.
Which is why the devices have to announce they support WebUSB to be exposed to any web apps, and can even restrict their usage to specific domains.
Because there's no such thing as a XSS attack?
...and that's why we have Web Bluetooth, which is already in the Chrome Dev Channel.
Seriously, this is the moment where we should just stop, kill all existing browsers, and start from scratch.
This is NOT acceptable, and this is probably the dumbest thing I’ve ever seen.
WebBluetooth, WebUSB, WebGL?
God I hope that this shit will never appear on any of the websites I visit, as I’ll make sure to patch it out of my browser.
It's shoehorning everything into ancient technology ill-suited for any of these applications, which is not exclusively Google's fault of course. First HTML was augmented with Javascript, which was augmented with XHTTPRequest, which led to an increased usage of Javascript (Here's where Google comes in), which led to a lot of manpower being invested in optimizing the Javascript engines (trying to run a quirky dynamic language as fast as possible) and then augmenting the browser with "native" OS features like:
* Full-screen mode
* Clipboard control
* Native notifications, with background workers, etc.
* WebMIDI
* OpenGL
* etc.
Which is basically like building a second operating system on top of the already existing architectures. Google tried to further push people this way by coming up with Chromebooks, which in reality actually serve to reinforce my point, since most (not all!) users find them just not sufficient enough.
That's what they said about JavaScript, and look how that turned out.
This is pretty much the web 2012, or most of German-language web today still.
For browsergames, let’s just use the same paradigm as with apps instead: Bundle them via node+webkit, and integrate a "run locally" API into browsers that automatically downloads a program and runs it locally in a sandbox, but seperately.
In the long term, for games we’ll need to develop a different concept anyway.
But there’s a good reason why no one develops 3D games in PDF, despite PDF supporting 3D objects, scripting, and modification of the document via scripts.
If the implementation allows access to these endpoints in a way that allows them to upload firmware, this is very bad for security.
If you accidentally plug your USB device into an unknown computer on a webpage, it's reasonable to expect that the device could have been reprogrammed. And a reprogrammed USB device may very well expose any descriptor(s) it wants to - HID keyboard, mass storage device, ethernet connection...
> USB hosts and devices historically trust each other. There are published attacks against USB devices that will accept unsigned firmware updates. These vulnerabilities permit an attacker to gain a foothold in the device and attack the original host or any other host to which they are later connected. For this reason WebUSB does not attempt to provide a mechanism for any web page to connect to arbitrary devices.
...
> For this reason this specification outlines two mechanisms that can be combined by the UA before a site is granted access to a device. First, so that the device can protect itself from malicious sites it can provide a set of origins that are allowed to connect to it. These are similar to the [CORS] mechanism and can conceptually be thought of as treating USB devices as their own origins in the "usb" scheme. For devices manufacturered before this specificiation is adopted information about allowed origins and landing pages can also be provided out of band by being published in a public registry. Second, so that the user's privacy is protected the UA may prompt the user for authorization to allow a site to detect the presense of a device and connect to it.
We've seen this exact recipe for years of pain play out again and again. C was designed when programmers wrote code for themselves and other people who weren't trying to break that code; if you manage to overflow a buffer in some command-line utility that uses "gets()", you're basically punching yourself in the face. SMTP was designed to send messages between non-commercial entities who wanted to communicate; then the people who stuffed your mailbox with ads realized they could stuff your internet mailbox with ads almost for free. In both cases, a system built for a trusting environment was used in an untrusting one, and there was much pain.
A public registry and an optional nag about an on-by-default feature won't come close to addressing the problem. With thousands of types of USB devices out there, who will go through and audit them all, and keep the registry up to date? And how many users will see the nag and just do the easiest thing to make it go away, or even have the knowledge to make the decision? It seems like browsers need an "annoying/harmful Web 3.0 features" tab with an ever-growing list of check boxes for WebGL, notifications, geolocation, USB, etc., with all of them set by default to "deny without asking."
Furthermore, this public registry idea also implies that a USB VID/PID directly correlates with a device. There are USB devices in existence that emulate another USB device in order to utilize built-in drivers (inbox drivers) and maintain compatibility with existing software. There are also different USB devices that use the same VID/PID to identify themselves, because in order to obtain a VID/PID, you have to pay a licensing fee, which is not always feasible to everyone. If this public registry is used, it may create conflicts. If the CORS-like public registry entries are always trusted by the browser, it could even create security concerns where remote computers are allowed to seize control of local USB devices.
It would certainly be concerning if USB devices were firmware updated without users' consent, simply by going to the website of the manufacturer. Or even a web advertisement that connects to USB devices...
In the future we may even see some kind of attack on web servers in order to gain access to the USB devices of unsuspecting users...
The WebUSB approach also limits each device to be connected and controlled by exactly one browser frame which makes it not very desirable for sensor and other input applications.
Why do you think that? It seems needlessly complex to me when you could just have a simple permission pop up in the web app. What's the benefit of downloading an executable?
Besides the permissions stuff giving a single browser window access to raw usb data seems also technically wrong. There are lots of reasons why we now have drivers instead of applications directly using the hardware like 30 years before. A driver or dedicated application can allow multiple clients (browser windows) to access the devices functionality. A driver directly embedded in a web page can't. A driver in the webpage even means that once you close that page the communication state between PC and USB device is in any state (can't see a way for automatically doing anything meaningful on goaway), so the only thing that could be done is disconnect and reconnect the device. So some further implications are: Multiple tabs for your web app are not possible. And even other stuff like Ctrl-R would not work as desired (disconnect device, reconnect device, wait, wait, wait, ...).
> Yes, we can do much of this by having the user install a local application that communicates via web sockets, but that has its own security implications and adds an additional step for the user.
You're target audience is arduino hackers, and you're worried about them installing an app? You need to seriously reassess your assumptions.
I always find it funny how each new browser and OS release makes it a little more hidden and a bit more convoluted to set it up. All while more and more web developers complain what a big problem secure authentication on the web is.
So yeah, I understand why adding this to a web browser seems unwanted, but as long as the API is well-defined and built with security as its first and primary concern, this could actually improve the overall security of on-line services significantly by making two-factor authentication something your browser just does, and does right. I can recommend skimming the Fido U2F spec [1] to anyone with doubts about the applicability and necessity of this standard.
The linked article basically starts with a section on privacy and security concerns though, so that is somewhat reassuring.
1: https://fidoalliance.org/specifications/overview/ (look for U2F in particular)