logoalt Hacker News

_kbtoday at 12:33 AM5 repliesview on HN

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.


Replies

dzdttoday at 3:34 AM

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

show 1 reply
arbolestoday at 6:57 AM

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

fsflovertoday at 8:27 PM

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

rustcleanertoday at 4:16 AM

This is one reason why I run Qubes OS as my daily driver.

mschuster91today at 6:28 AM

> 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