> 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 qubes-users@googlegroups.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.

Reply via email to