| HN Mirror

Why is it a security vulnerability? I really want WebUSB to succeed, it could be a cross platform way to eliminate random executables from shady websites.

The idea is that your browser can mediate and scope access to specific devices. There are some edge cases where Web USB is equally as dangerous as the status quo, but in the common case it is far better and never worse.

The situation today is you buy a random USB gadget (e.g. a fitness tracker), but you can't use it without also installing the accompanying software/drivers. That effectively gives the manufacturer complete control of your computer. All you really wanted was for them to sync your step count, but you have no option but to give them complete remote access to your computer.

With Web USB you can allow vendor.com to access device 1234:5678 only, and revoke that access whenever you like.

Sure, maybe you could be tricked into clicking through all the confirmations and granting https://fakevendor.com access to a device. That could be bad - but no worse (and probably a lot better) than being tricked into downloading and running fakedriver.exe.

(disclaimer: I work for Google, have nothing to do with Chrome)

I explain in a neighboring comment: https://news.ycombinator.com/item?id=34563795

It's crucially important that Googlers are divorced of the belief a permission popup on the top of the screen is adequate indication of intent/informed consent. People approve these all the time without understanding what it's for.

Installing software is, at minimum, a very distinct action which users are aware of doing. Generally, they install a limited number of applications for specific purposes, whereas they may visit literally thousands of websites a month. Pretending these two things can be interchangeable is silly.

I am not entirely opposed to being able to use a browser as the UI for an activity like this, but it should require a higher bar to activate it for a specific server to talk to a specific device. Even web extension installs remain far too easy to not be maliciously abused widely. (Chrome extensions remain the primary malware I see in the wild.)

EDIT: The HN gods have me rate limited so hopefully you'll see my response here to the below comment:

Installing software is a complex process. It entails navigating to the correct site, locating a download, fishing it out of the downloads bar (many seniors cannot find this, by the way, it absolutely baffles them), opening it, usually acknowledging that you know it's an executable program, and then navigating the install wizard.

A software engineer would reasonably believe simplifying this is a good thing, but as noted, people regularly accept malware into their browser and do not even consciously realize they did it because it involves a single click.

People absolutely get misled into installing bad software, but they always know they actually did it, it's impossible to follow that chain without having some idea you're doing something.

Accepting malware isn't the answer, understanding people is. There is no technical solution for security, because it's a human problem.

Why is installing software a distinct action, but granting device access not?

Malware is a huge ongoing problem, which suggests this distinction doesn't really exist.

I think we have to accept that there is no way to perfectly eliminate social engineering without also locking down legitimate access to devices. There will be some percentage of users who will click through all the warnings and confirmation prompts, just like there is some percentage of users that will run malware. That's bad, but you're letting the perfect be the enemy of the good.

Your argument could also apply to ssh, a small number of users could be socially engineered into sharing their id_rsa. This happens, we often find them checked into github, for example. Does this mean we should go back to telnet? No, for the vast majority of cases ssh is a huge imperfect improvement.

Likewise, in the vast majority of cases, Web USB is a huge imperfect improvement over installing drivers.

So the issue is we are talking about different dimensions of improvement. I concede that WebUSB is better sandboxed than executing a driver installer (likely running as admin or root) in terms of the blast radius. However, WebUSB is catastrophically worse than an installer in terms of the ability of the infection to occur in the first place. Both because of the aforementioned difficulty of user process of software installation, as well as the additional checks the OS and/or third party antivirus does, as opposed to Google's fairly limited abuse detection capabilities (just Safe Browsing in WebUSB's case, I imagine?).

This is a problem I have talked about many times before regarding Google's security outlook. On Project Zero there's a ton of interesting and surely exciting work into novel ways to compromise systems. ...That work has basically no bearing on improving security for the billions of users who will never be targeted in such a niche technical way.

Real world compromise tends to just be social engineering people into doing what Google explicitly permits websites to do. You could remove malicious activity from a billion users right now by simply... deleting the Notifications API from Chrome, which is principally used to spam ads. Because people mash that allow button all the time, every time.

I'd best guess I see ten times the malware in Chrome (either hijacker extensions delivered by the Chrome Web Store, push notifications from random adult websites, or both) than actual installed malicious software on a given Windows machine.

And this is fixable! Google could fix this with WebUSB and make a net positive all around! Likely by redesigning permission granting in the browser to require deeper user intent. But it would require a fundamental change in how Google understands and perceives security (and it'd likely reduce engagement stats for some features, which various teams would fight), and I've been beating this drum for several years and I don't really expect it to change.

(In fact, one specific change I could recommend: I think APIs like WebUSB, as well as the Notifications API and similar, should probably be completely blocked unless you install a PWA. It's not as much process as a Windows software install, but it's a clear gate to allowing a site more ability, and installing and removing apps is a far easier concept to explain to users than navigating the site privacy settings.)

I think I need to see some data to back up your claim that Web USB makes socially engineering "catastrophically worse". Web USB is deployed today for a billion users, and yet attackers still seem to prefer malware or walking victims through installing TeamViewer, correct?

We're not talking about any vulnerability here, this is social engineering. There is no amount of confirmation that can be required or warnings added that a confidence trickster cannot walk you through dismissing. The only solution is to limit what you're allowed to do with your own computer.

That's a really high price to pay.

Ah, but before they got tricked into TeamViewer, they were likely compromised once or twice over by Google: It's likely the link to the scammer's screen came from a Google ad that directed a user to a browser hijacking web extension, all of which has roughly the same level of difficulty as WebUSB. Then after that, a scammer may talk them through the process of downloading a RAT. (Though TeamViewer has not been popular for this in a while because they are responsive to security reports. There are some overseas-based tools which have taken over exclusively in the last few years because the developer doesn't answer their email.)

WebUSB is new, non-standard, of course, and last time I tried it required feature flagging (it's saving grace... at the time). Compromises through extensions are probably more likely for a while, but WebUSB will probably be more exciting for persistence, considering you could flash an entire hardware device with malicious code, that the user has already demonstrated comfort connecting back to their PC.

saagarjha 1239 days ago

It depends on your threat model. “A trusted party ships high-quality drivers” is a good model but bundling it with the browser, where you run all sorts of code from third parties, can be difficult from the perspective of exposed attack surface. I would expect that someone in the position that ‘ocdtrekkie probably blocks installing random third-party drivers on those machines anyways, so now there’s new a way for websites to do funny things to connected devices at best and pwn your computer because the high-quality USB implementation wasn’t that high quality after all. (I’m putting aside the conversation about phishing people into granting those permissions, because that’s a completely different, difficult discussion.) Also,

> disclaimer: I work for Google, have nothing to do with Chrome

…depends on how you’re squinting.

> pwn your computer because the high-quality USB implementation wasn’t that high quality after all.

You have to compare it to the options we have available today, not an implausibly perfect implementation that doesn't exist.

Let's imagine there is some bug that means if I grant access to a device, then more access than intended is actually granted. That sounds bad, but let's compare that to the non-Web USB model, where you have no option but granting unlimited unrestricted access to everything... now it doesn't sound so bad :)

Isn't "if you can find an 0day exploitable bug you can get access to everything" better than "You don't need a bug, because you already have access to everything"?

> …depends on how you’re squinting.

Umm, I know what I work on?

saagarjha 1239 days ago

I think we're talking past each other. If the two alternatives are "I need to use a random native USB driver to talk to this" and "I can use WebUSB" then WebUSB is probably better. But in reality a lot of devices actually already have drivers for that class in the OS, or there's a way to write some sort of restricted driver on that platform doesn't require loading things into the kernel. In that case I'm now using a browser where random websites can either trick me into giving them access to my USB devices with a click, or forcefully access them via an exploit on a surface that is generally amenable to such things. Put another way, I see WebUSB as being an attempt at writing userspace USB drivers by doing it in Chrome instead of the OS, and considering the entire point of using Chrome is so people can run code on your device it might be better to actually not put this capability here.

> Umm, I know what I work on?

As do I, and it would probably be more accurate to write "I work for Google, but not on Chrome".

> But in reality a lot of devices actually already have drivers for that class in the OS

Great, then you don't need to install anything or use Web USB, it's a no-op!

Still, until we can get Microsoft to ship every driver for every device, we still need a solution that works today.

> In that case I'm now using a browser where random websites can either trick me into giving them access to my USB devices with a click,

You can already be tricked into granting complete access to your machine with a few clicks, that's malware. It's a huge ongoing problem that can only be solved by limiting the ability to run third party code. That's a really high price to pay.

Sure, you could be socially engineered into granting an attacker access to a USB device. The only solution is to have no way for you to grant access to USB devices. There is no amount of confirmation or warning you couldn't be tricked into dismissing by a social engineer.

You will also need to uninstall Remote Desktop and OpenSSH, because you could also be socially engineered into configuring them to allow access. It's a common scam to trick people into downloading TeamViewer, so we will also need to remove your Administrator access and setup AppLocker with a strict policy.

> or forcefully access them via an exploit on a surface that is generally amenable to such things

That's not how it works. When a vulnerability is described as "arbitrary code execution", that means the code can do anything, not just access functionality that exists in the browser. If you were to use a browser without WebUSB support, an arbitrary code execution exploit would still be able to interact with USB devices.

The only added complexity here is after you've granted access to a device, otherwise the attack surface is entirely tractable.

This is a technical view, not a human-centric view. There is absolutely a level of warnings that will generally work. Not always, but I've found a number of people in the process of being socially engineered trip up on the UAC prompt and become more suspicious, to the point of booting a scammer out of their PC... and calling me. Likely because of the full-screen effect design and the short, but relatively scary language of the prompt.

You've posited effectively that if we cannot stop people from compromising their computer we should not bother to try. Either let them be owned with a trivial popup and a single press, or remove their agency entirely.

However, a better approach to security would be to take responsibility for designs that allow easy compromise, and build systems designed to drastically reduce the likelihood a user compromises their machines.

We can't stop people from finding a shady installer for a driver on a file sharing site hosted in Russia and running it, but we can make 99% of people less likely to do it with good design.

blooalien 1239 days ago

Assuming security is a well implemented "first class citizen" and not an afterthought, yes…

Let's assume it's an absolute trash fire, the latest of all afterthoughts.

That's still better than "just download and run this exe as Administrator".