-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Thu, Sep 01, 2016 at 06:55:05AM -0000, johnyju...@sigaint.org wrote: > > 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.
On, it's about compromising system to which such USB device is connected. > > 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. Actually our VM audio solution is based on something like this: passing raw samples (similar to pacat + module-simple-protocol-unix) over vchan link - socket-like inter-VM connection. See here: https://github.com/QubesOS/qubes-issues/issues/1590 > 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 I've looked at it few years ago and it was outdated/unmaintained at that time already. I gave up on setting this on Win 7. I bet now it's even harder. > 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)? If you assign a single USB device to VM (using qvm-usb or qvm-block), then yes - all the nasty USB stuff is still handled in dom0/sys-usb. Only assigning the whole USB controller (PCI device) to a VM will move USB processing out of dom0. > > 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 Very interesting project indeed. And it is packaged in Fedora! But as you've noted below, if all we need can be done using udev rules, it's better to not introduce another complexity. > 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. The whole idea of having separate USB VM is to not care about USB related compromise. It isn't fully possible with all kind of devices (like USB camera - compromised USB VM will be able to sniff the traffic), but it is surely an improvement. It would make sense to have Disposable USB VM - I hope we'll manage to have it in Qubes 4.0. > 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. Yes. But then, such device would be able to communicate with only one driver - of that keyboard. Not arbitrary chosen one of hundreds of them -> large reduction of attack surface. Of course, if it hit unlocked system (or locked, but know the password), controlling keyboard means controlling the whole system. But you can guard against such attacks with 2FA: https://www.qubes-os.org/doc/yubi-key/ (check also "USB keyboard" link at the top) > 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)? If it will clone all the device properties (vendor, product, interface etc), you'll see two identical devices. The only way to differentiate them would be to look to which port are plugged. > 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. It all make sense _in addition_ to move USB out of dom0, to USB VM (sys-usb, or multiple of them). > 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 is indeed interesting project. I think I've seen something similar for USB storage (to avoid USB disk pretending being a keyboard). But the one designed specifically for HID devices could do one additional thing: encrypt+sign all the traffic. Then such encrypted HID traffic would be decrypted in dom0, so USB VM would _not_ know the key and even when compromised will have very little ability to manipulate real keystrokes (or inject additional ones). This will not guard against some timing attacks etc, but still would be an improvement. > > 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. Even when USB keyboard is used, it is still good idea to move USB controller out of dom0. This may not be easy in some cases (if your USB VM crash, you'll lose keyboard access), but at least will make attacks slightly harder (from "run any code you want", to "inject any keystrokes"). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXyHkBAAoJENuP0xzK19cs+qMH/2wnIuv/qFYc7jYJ1wp/CeU4 OsA4S6YcrXCwRIeIijmJPJVRczU9hdZZlSQUXaapcKaveyWAiA0B6OThFTPkPs0e nRe/WDFZevZMdTppJbpU6XwjReXrsj/MpaI49AJ4Qcyc5rJmjYZbRR0dM+7ueODF 4Oi4Ho0f2RMn78oIQRFoAe7pyShq9I+As1gb5NU/Oaf4PERKie6RoWQAzzl8Rlib xcHysXAozvqaKkJU4tyu6zlupP6pQieG3+SESWH3uhXzxv/dsvQal0Eao1gMYO6h C9FI9Ol+9PQ9/1wFu/+CB8xdRBwAxmn6G5oSBvTK/kLZVgQsJ3htQgdPCur37Io= =NkRK -----END PGP SIGNATURE----- -- 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 qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20160901185248.GB328%40mail-itl. For more options, visit https://groups.google.com/d/optout.
