4 ms·
Short version: A bug in a Linux USB device driver can be caused to take over a Linux machine by plugging in a malicious USB device. An attacker would either use
by jimrandomh 11y ago
Short version: A bug in a Linux USB device driver can be caused to take over a Linux machine by plugging in a malicious USB device. An attacker would either use a custom USB dongle, or a programmable device with a USB connection such as a cell phone.
There's a narrow problem here, which is the bug in the device driver. That'll be fixed of course, now that it's gotten attention. But fixing this bug will not solve the problem, because there is a truly enormous number of different USB device drivers, most of which are poorly audited, run in kernel space, and correspond to unusual hardware. The real problem is that plugging in a device can cause any obscure device driver to load, without user confirmation. So for example, someone can plug in a cell phone, and the cell phone can claim to be an obscure kind of printer that no one has seen since the 90s, and the system will go ahead and load that device driver.
The solution is to require user confirmation before accepting any USB device that hasn't been seen before. Just a simple popup: You have connected [type of device], Ok/Cancel. The only tricky part is input devices like keyboards and mice, where this could create a chicken-and-egg problem with the confirmation prompt. (And devices pretending to be keyboards can be dangerous; they can type commands). Fortunately, there is a solution, albeit one which will take some programming work: accept keyboard input from keyboards that have either been confirmed by a prompt or have typed the user's login password. (Since some "keyboards" are actually things like barcode scanners).
- deleted 11y ago[deleted]
- contingencies 11y agoAnother solution is to not compile drivers that you don't need, and to take minimizing kernel attack space as seriously as running a firewall. It should, in my opinion, be routine to run a reduced kernel in production, however most of the industry appears to use stock kernels from a few major vendors. The likes of CoreOS are probably helping here. Keep it up.
- geofft 11y agoFor a server-ish machine, disabling module autoloading is fairly straightforward: set /proc/sys/kernel/modprobe to /bin/false. (You can also do something fancier like https://scripts.mit.edu/trac/browser/trunk/server/fedora/config/etc/scripts/modprobe https://scripts.mit.edu/trac/browser/trunk/server/fedora/con... to report what the process is.) This is also useful to disable modprobing obscure networking protocols just by an unprivileged process calling socket(SOCK_STREAM, AF_FULLOFBUGS, 0), which was a fruitful source of exploits at least a few years back. However, for most server machines, if an attacker can plug a malicious USB device into your machine, something has already gone very wrong. (And for a good chunk of servers these days, they don't even have USB because they're VMs.) The primary threat model for this sort of thing seems to be laptops that are briefly left unattended and locked, or "Hey, can I charge my phone off your laptop." For the unattended-and-locked case, perhaps you could block module autoloading until the user has logged back in. It's roughly similar to the approach Apple takes with Thunderbolt, I believe.
- chei0aiV 11y agoThe likes of Amazon can plug virtual USB devices into your VMs.
- geofft 11y agoIf you're worried about the people who run your servers compromising your server, find different people to run your servers. There are a million easier ways to break into a virtual machine running on a physical machine you control than finding an exploit and writing code to emulate malicious hardware. You can just modify memory directly.
- chei0aiV 11y agoIndeed, the cloud is a huge problem.
- contingencies 11y agoMy point was not just to disable modules, but to disable all kinds of unrequired kernel functionality. Recall recent vulnerabilities such as BPF JIT spraying, etc.