tech-security archive

How trustworthy is that I/O device?

To : tech-security%netbsd.org@localhost

: Subject : How trustworthy is that I/O device?

: From : Erik Fair <fair%netbsd.org@localhost>

: Date: Mon, 4 Nov 2013 14:34:37 -0800

All OSes have a problem with USB and potentially all other hot-plug I/O busses: can you trust the device that was just plugged into the bus? How much I/O do you permit to it before explicit authorization of some kind? NetBSD handles storage devices OK: kernel reads the label, but nothing more until an FS is mounted. That's probably safe, provided that our label-reading code is bullet-proof against bad (or possibly malevolent) label data. Things get dicier when they're Human Interface Devices (HID, e.g. keyboard, mice, trackpads): those NetBSD attaches to wscons(4) automatically and take input from right away without further vetting. While convenient for users, this leaves a system open to attack from such devices ("Gee, it looked like a USB thumb drive; how was I to know it was actually a keyboard programmed to send "rm -rf /" to whatever it plugged into?"). By contrast, we (and pretty much everyone else) are a lot more suspicious of computer network connections (e.g. Ethernet, WiFi), until we look at Bluetooth. Input devices again. My characterization for this sort of thing turns somewhat on "distance" from the CPU(s) and whether the I/O device is hot-plug or not; we trust RAM (pretty much have to, but ... NUMA clusters, anyone?), we (to some degree) trust GPUs, we trust the disk we booted from, we trust (to the degree we find it's not buggy) system firmware. Netboot server? SAN? We tend to trust PCI devices - they're in our computers. Oh, but now we have to think about Thunderbolt. We might want to make a distinction between (presumably physically secured) sessile "desktop" or "server" machines, and portable systems like laptops or hand-helds which are more likely to be used in "hostile" environments - I'm not looking for just one security policy, but we should think through our use cases and associated defaults carefully. My model is not well-formed; I merely observe how OS kernel code trusts or doesn't trust the I/O devices it interacts with. I think we might want to rethink some of that interaction in light of the modern age of computing & networking, and the amount of hostile stuff going on. Some philosophizing about security models and tradeoffs with usability, with an eye towards being a bit more resistant to attacks from things people randomly plug into their computers. Erik <fair%netbsd.org@localhost>