Comment by teddyh
1 day ago
Key takeaway:
> 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.
The preceding sentence is equally prescient:
> 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.
[1] https://github.com/AristoChen/usb-proxy
> > 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
Some operating systems can protect you from that. See: https://qubes-os.org.
This is one reason why I run Qubes OS as my daily driver.
> 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.
[1] https://en.wikipedia.org/wiki/HDMI#HEC
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?
[1] https://web.minidisc.wiki/
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.
8 replies →
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.
All mics are analog.
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.