> On Wed, Aug 31, 2016 at 10:05:59PM -0000, johnyju...@sigaint.org wrote: >> I'm curious to some mentions-in-passing about Andrew's hate for USB >> keyboards. USB-anything isn't good for security, but what in particular >> so much worse about USB? Both USB and PS/2 can keylog, or play >> predefined >> scripts to try and exploit the system. One of the dangers of rogue USB >> devices is that they can suddenly pretend to be a keyboard (which Linux >> will accept without confirmation, something I'm not thrilled about). > > It is mostly not about the keyboard itself, but other devices on the > same bus. Anything that can control the bus to which keyboard is > connected, can control the keyboard / pretend to be a keyboard.
I can understand pretending to be the keyboard, but seeing the keyboard's traffic, controlling the keyboard is really possible from another device on the bus? If so, what a fatal flaw in the design of USB. > In addition, USB is quite complex and as with all complex code there are > bugs. I hear you. I've bit-banged PS/2 protocols myself, and it's not that hard. VUSB has achieved the same with USB, but its a *huge* project (and can barely achieve HID use). > If you (or someone else) plug a malicious USB device that will exploit > some bug in one of million USB device drivers, it can do whatever it > want with the other USB devices on the same bus. And if that USB > controller live in dom0, it's game over even without injecting malicious > keystrokes. Yikes. USB really needs to get out of dom0 all together, just as networking has. I'd also like to see the sound card in its own VM. With Pulse's networkability, it shouldn't be that hard. One could use the Pulse network ability instead of virtualization of the sound card. That might also be the best route to getting sound working in Windows HVM's, although some work is needed on Windows Pulse clients: https://freedesktop.org/wiki/Software/PulseAudio/FAQ/#index15h3 When I assign a single USB drive to a VM, is dom0 still really in charge of the USB bus, and just shuffling stuff back and forth to the VM(s)? > PS/2 is much better, because you can't connect anything else than input > devices there, and attack surface is much smaller. Agreed. It's all I use for mouse/keyboard. > Some mitigation would be to use separate USB controller for USB > keyboard/mouse and have it in dedicated VM (separate form all-purposes > sys-usb). Another possibility is some built-in Qubes support for building udev rules (similar to how the firewall makes iptables rules), or perhaps adding USBGuard to dom0 (or any USB Qube). A good comparison of the two options is here: https://dkopecek.github.io/usbguard/blog/2015/USBGuard-vs-UDev Seems like a great idea for Qubes in mitigating USB dangers, since in practice it is so hard to avoid USB all together. And that problem is only getting worse. One dodgy USB device from the dollar store, and your pwned. Or an NSA/syndicate-implanted commercial hard drive with alternate identities lurking. I'm always tempted, but ultimately avoid, unusually low-priced USB devices, lol. I've been passed USB keys from some rather suspect individuals in the past; I've quarantined them, and should (carefully, on a non-critical system) take a more detailed peek someday, lol. Some discussions online argue that USB white-listing isn't helpful, since a BADUSB could just emulate your actual keyboard. Well, it would have to know the device ID's first. Even if it gloms my keyboard's USB vendor/device ID's and tires to imitate it, the system could spot the fact that there's a second similar device but on another USB port, no? Or is USB so stupid that the system couldn't differentiate the two (or the fact that there is two)? While the USBGuard project looks admirable, I'm guessing the more attractive option would be for Qubes to add support for creating custom udev whitelists, as the less software in dom0, the better. Although USBGuard isn't a huge project (the tarball is <1M) and if you're going to otherwise have to write the code yourself, it might be better to just audit USBGuard and include it in some form. If someone else has already put in much of the required thought and effort . . . Even a pop-up notification when a new HID device is added could be useful. The fact that keyboard/mice are silently accepted is a bit scary. I might add some scripts to watch dmesg for such events, and more actively warn me. All just food for thought. I'll be adding udev whitelist rules to dom0 very shortly. Another idea I saw was restricting HID devices to *one* keyboard and *one* mouse, so if a BADUSB comes along trying to be another keyboard, it doesn't work. Or even better, alarm bells go off. I was thinking earlier that some form of a "USB Firewall" hardware device might be cool to create; one that goes into each USB port in between each device and the PC, and only passes a specific device, or only a HID device (and doesn't permit a drive to add another HID identity). Yet another side project for winter. :) There may be existing products. > This will guard you from potentially malicious devices *you* plug into > the system, but not from someone else plugging it instead of keyboard > (so into that keyboard-only USB controller). This is scary: https://hakshop.myshopify.com/collections/usb-rubber-ducky/products/usb-rubber-ducky-deluxe?variant=353378649 > To plug that hole, that > USB-keyboard VM should be configured to reject any non-keyboard device > before allowing any driver to talk to it. This will still left you > vulnerable for bug in USB stack itself, but the attack surface is much, > much smaller than all the USB devices drivers (some unmanaged for > years). Very interesting. Where dom0 is currently in charge of the keyboard/mouse, and I assume won't be separated out (even by 4.0?), I think some udev rules or USBGuard might be called for. JJ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to email@example.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e677364658988d4b2c3428ea8f7adb78.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.