> And the existence of WebUSB, WebHID, and WebBluetooth mean that for some devices, depending on the specifics of which classes are used, a moment of user indiscretion in accepting a permissions prompt could permanently backdoor one of their attached devices.
> Operating systems aren’t really equipped to work with the user to ensure that a microphone stays a microphone, and doesn’t spontaneously turn into a keyboard that hits Win+R and drops a payload to steal all your data when the room is quiet enough that it can assume you aren’t watching.
In a world of USB-C everything we no longer have power supplies that are physically bound to power delivery, HDMI or DP display connections that have constrained data channels, or analogue mics, headphones, and speakers. Any device can dynamically change what it senses, does, or emits.
Was daydreaming the other day about how this could be used by adversaries to hack even air-gapped computers. Any peripheral which contains a microchip and some ram is a vector. Does the compartmentalized facility ever bring in a new monitor, or mouse, or keyboard? All of those things could be hacked to hack their new host. And then taking data into/out of the facility. Which devices have lights? Any LED that can be blinked is a low-speed output channel. Which have light-level sensors, or sound sensors? Or any RF capability? If bluetooth is disabled by software but the hardware is still there...
If I was writing a novel, the top secret facility would be cracked open by the smoke alarm, which has a wired connection to the central fire control and runs a little microprocessor. There is enough storage for 20 programmable voice alert messages. I/O includes an LED and also a light sensor. After the attacker gains control of the smoke alarms -- reach to every room of the secure facility -- their focus turns to mass poisoning peripherals until one makes it into range. A poisoned monitor detects the smoke alarm blinking a coded broadcast via its LED during darkened overnight hours. The monitor responds with flashing code of its own. That creates a communication path back to the controlling LLM. From there its like attacking a normal networked device, just with a slow data link in the middle...
In environments where the threat model requires it you can/must already buy hardware variants that are non-radio. It's not just disabled in software but is a different physical SKU. Likewise data diodes for USB, audio, or display connections are also common.
The novelty is the uniform adaption of USB-C for the rest of the world and the endless attack surface that provides.
I recently realized something similar. I think that usb-proxy[1] could be used to force what looks like a mass storage device to stay a mass storage device, and likely could be built to be a sort of firewall. usb-proxy is a toy project showing that you can physically "MITM" USB with an RPi, but it could be a starting point.
> HDMI or DP display connections that have constrained data channels
HDMI has theoretical support for 100 MBit/s Ethernet [1] but in practice I agree, haven't seen that one used in practice.
IIRC it came in 2009 with HDMI 1.4, at that time Wifi in practice was mostly 802.11g with IIRC 20-ish MBit/s as 802.11n was still formally a draft... the idea was to give high-bandwidth networking to home entertainment devices without requiring to run physical Ethernet to each tiny device, but it quickly became superseded by 802.11n Wifi on one side, and on the other side, the "enrichment" of stuff on DVDs or broadcast TV with internet-based content never truly materialized.
> > Operating systems aren’t really equipped to work with the user to ensure that a microphone stays a microphone, and doesn’t spontaneously turn into a keyboard that hits Win+R
This is why most of the browsers rejected these specs. They are super useful, but the security risks are incredible. Most USB devices were not designed to hold up to being exposed to the internet.
I kinda remember that the counterargument Google used is that only devices with a special attribute would ever be available through WebHID, ensuring that such older devices would never be exposed.
Cue my surprise when it turns out you can use WebHID to program a Minidisc / Net-MD device [1], so.. they never did implement that filter, apparently. I mean, certainly it is useful, but ... What The F., Google?
The user has to first specifically pick the device from the list and grant the website access. If a user is confused by a permissions prompt and has no idea what is going on, the default path is to reject the permission.
In the real world the default action for a user when presented with a permissions popup is to accept it because they get asked 20 times a day, have no idea what the implications of it are and just want to get on with their day.
So software designers need to avoid asking the users to approve potentially highly dangerous things.
This is untrue. Chrome's "acceptance rates" for proceeding through its bad SSL cert warnings used to be pretty high, but with a redesign they basically flipped the numbers so most people didn't proceed to connect to the site. Similarly with cookie banners, where making it more difficult to say no (by e.g. moving a decline button to a second interaction layer) meaningfully raises acceptance rates; if users were just blindly accepting everything, then there'd be no reason to make it harder to say no. Apple's App Tracking Transparency (ATT) prompt has users overwhelmingly answering no even years after introduction (though of course opt-in is increasing). A study on permission prompts in Android found that the main factor in first-use denial rates was whether users thought the app needed the permission it was requesting or not, showing some actual comprehension of what they're being asked. Another found higher denial rates if the frequency of the prompt was on every access instead of once, rather than apathetic blanket acceptance.
Design prompts for potentially dangerous actions so refusal is easy and what's being asked is legible, and people will refuse plenty.
I think Safari does this with popups & downloads. Tiny little icons that barely appear [to change]. Can annoy me when I miss them but sometimes I figure maybe it’s for The Greater Good.
You realize that most of the time that you are giving access to an older HID device, you are giving the website permission to convert that device into a persistent backdoor forever? No matter if you later close the browser or revoke the permission -- the damage has already been done? Most devices predating WebHID and the like have almost no protection (why would they?), and you can corrupt or even entirely replace the firmware quite easily. heck, NetMD is one example (the browser can overwrite its firmware with no trouble!), as are the devices listed in TFA .
It is basically the same reason most desktops do not give the logged in user access to /dev/hidraw*, even though it makes a shitton of sense and would simplify many things greatly.
This is one of the few areas where I think Mozilla did the right thing without question.
WebUSB has been live in Chrome for 9 years and nothing happened. Compare to all the features that result in people getting hacked every day. Your threat model is ridiculous.
Look, I find it funny that I find myself arguing on the other side of the discussion that I'm frequently on, but here is where I draw the line, and I think what is ridiculous is to think otherwise.
How many hoops Google asks you to go to install an Android app ? (Androids amounts to basically the most sandboxed environment one can have today; malware installed there can practically do _nothing_) MANY. Centralized register of apps and remote blacklisting, a lot of permission prompts, password check, and they are even literally pushing to even have a physical 24h cool-off period if you skip the centralized register.
How many hoops does Google ask you to go an allow a random website unfettered access to destroy your hardware? One. Permission. Prompt. In a bubble prompt, that barely registers above noise compared to other permission prompts browsers ask.
Of course these are two ridiculous extremes, but they exemplify the point. There is a reason a browser won't allow a random website to write over random sectors of your hard disk just because you said "accept" to a bubble-style permission prompt about wanting to "save files to your hard disk". The line has to be drawn somewhere, and allowing what basically amounts to raw access to IO ports just after a single permission prompt listing the device name is where I draw it. Any user, even knowledgeable ones, is simply going to be _incapable_ of truly understanding the risks behind allowing this access.
I would be much more in favor of allowing random IPC to services in your local computer (after a permission prompt) than this., something that is equally useful if not more than allow raw access to HID.
Devices need to be hidden behind drivers that multiplex and control access to the device at the OS level. A bus that was never meant to be exposed to user-level access should not be exposed to random programs much less websites. This is not security, this is "mistake prevention" level, in the same way operating systems disallow a random user-level program from overwriting the hard disk.
And do not read this as "devices should sign their firmwares and what not". That is (for me) definitely the wrong take but literally the only take that is left on the table due to Google's stupid behavior.
> How many hoops Google asks you to go to install an Android app ? (Androids amounts to basically the most sandboxed environment one can have today; malware installed there can practically do _nothing_) MANY. Centralized register of apps and remote blacklisting, a lot of permission prompts, password check, and they are even literally pushing to even have a physical 24h cool-off period if you skip the centralized register.
I 'member (and miss) the old Android days before everything became the locked down hellscape Android is these days. And I also member why it became that way, there was a loooot of bad actors exploiting that open model.
For operating systems it's similar. DOS/Windows up to and through ME didn't have the concept of different user levels, the file system didn't allow for it, and if you had physical access to the machine it was trivial to corrupt and subvert it. Only with Windows XP, Microsoft switched the consumer OS to NT and its multi-user model.
And so it will be for WebUSB et al. First it will be a pretty open and unrestricted world, and only if there turns out to be a significant problem, security will (need to) be tightened.
WebHID being used to access a microphone is risky though. Microphones are already often exposed to web browsers, so asking for microphone access wouldn't be out of the ordinary.
Maybe MD drives aren't really at risk, but things like HID peripherals definitely are.
Note that when you say “rejected”, Mozilla’s position has actually shifted a bit. At the end of 2022, it shipped MIDI in the form of an extension that it will prompt to install for the purpose, with more detailed information and a couple of other details that make it less unsafe. After a few years of that, consensus has grown that this seems to be working acceptably, and that the technique may be considered for other risky areas. They haven’t said anything about USB publicly, to my knowledge, which is definitely way more dangerous than MIDI (even SysEx), but I have heard one rumour (of dubious provenance) that they may cautiously proceed with USB and such too some time soon. Though this sort of thing definitely weighs against that, showing that maybe they were right the first time.
The key takeaway for me was he bought a $300 microphone and is acting indignant that he has full access to his own hardware via — gasp — a command shell.
Do we live in a bizarro world now where we expect — no, demand — our hardware be locked down?
It's worth mentioning all USB mics are toys anyway. Analog interfaces have gone away — artificially so — now they cram them into the device.
You make a good point: hardware should not be default-locked from owner control and manipulation in the name of security. In fact, in the name of security, the default should be open enough to not only manipulate and reflash through owner accessible channels, it should also be easily flashable through chip clips in the worst case compromise scenario. Owner control of all Universal Machines in an object he owns must be a paramount right, akin to the first and second amendments in the bill of rights! This includes your game consoles, vehicles, stoves, washing machines, TVs, microwaves, and even that Qualcomm processor in cellphone basebands. If it is a Universal Machine which executes code from writeable storage (or firmware/microcode provided to it, like during OS boot or driver initialization), it must permit owners to change it. If it comes with cryptographic integrity check keys, the owner must be able to both write his own keys and purge the OEM's keys. Behavior should not change, even the warning Google Pixels give immediately on turn-on are unacceptable, unless it does it by default for the OEM's keys and firmware too; no change in product behavior or appearance when an owner exercises his right to modify his Universal Machines, except where the change arises from the firmware itself that the owner applies.
> And the existence of WebUSB, WebHID, and WebBluetooth mean that for some devices, depending on the specifics of which classes are used, a moment of user indiscretion in accepting a permissions prompt could permanently backdoor one of their attached devices.