LWN: Comments on "USBGuard: authorization for USB"

An open USB "firewall" is available (and works)

Herve5 — Sat, 03 Feb 2018 13:20:21 +0000

Just for the record : I ordered, received and all is perfect here ;-)

USBGuard: authorization for USB

nix — Thu, 23 Nov 2017 20:43:54 +0000

Yeah, I was thinking specifically of OTP usage, but you're right, they can type in other stuff too, I just don't use those features so I forgot about them. :)

USBGuard: authorization for USB

itvirta — Thu, 23 Nov 2017 14:54:50 +0000

Well, yubikeys can also send tabs, variable length public ids, and arbitrary static passwords.
And they can be configured to not send that final <enter>.

USBGuard: authorization for USB

nix — Wed, 15 Nov 2017 00:25:34 +0000

Oof. True! So you do need to allow return. I suppose you could require that the inputs be the right *length* as well (not just alphabetical but a 44-character-long alphabetical sequence terminated by return), which means that you'd only be at risk from a hostile device if the user being attacked has commands named things like "rmrmrmrmrmrmrmrmrmrmrmrmrmrmrmrmrmrmrmrmrmrm" that do dangerous things when run with no parameters :)

USBGuard: authorization for USB

nybble41 — Mon, 13 Nov 2017 16:21:01 +0000

> it's hard to do anything malicious when you can't type return or tab or space or any punctuation

For what it's worth, a genuine Yubikey will type a return character at the end to submit the OTP. This is more of a convenience than an actual requirement, as long as you have a normal keyboard attached, but it would be a problem if the device was rejected as "non-genuine" just because it generated a non-alphanumeric character.

USBGuard: authorization for USB

nix — Mon, 13 Nov 2017 15:02:42 +0000

Unfortunately Yubikeys themselves register as, uh, keyboards. (That's quite a lot of the point of them.)

They do have authentication modes that involve direct USB communication (challenge-response, CCID, U2F etc) but if you're relying on OTP entry, then you'll need to add some extra authentication somewhere to ensure that the keystream coming from the thing that looks like a Yubikey is actually Yubikey-like (roughly, 'lowercase letters only' though honestly just excluding non-alphanumeric characters would suffice to stop an attacker masquerading as a Yubikey keyboard from doing anything too bad: it's hard to do anything malicious when you can't type return or tab or space or any punctuation).

USBGuard: authorization for USB

gdt — Sun, 12 Nov 2017 02:19:08 +0000

It's a relatively recent allocation. Your point is good and I'll send a patch to the udev people so we can nip that in the bud. The range is already blacklisted in another operating system.

USBGuard: authorization for USB

gdt — Sun, 12 Nov 2017 02:15:58 +0000

Perhaps a better example would be that we allow the class of items like Yubikeys but deny all other classes. So that only Yubikey-like objects can go into that slot (not ethernet/wifi dongles, keyboards, mice, storage, microphones, cameras, etc). That's a powerful denial, since even if an object fakes into the Yubikey-like class then it can only do Yubikey-like things, not unexpected things, as the drivers which support those unexpected classes won't be attached.

This article certainly encouraged me to install the software, to set most of the USB ports on the laptop only allow the storage class, and to set the USB-C port to only allow the classes I saw already plugged into that desktop expander. That's a modest but useful improvement in security for the trouble.

Locking your keys inside

flussence — Sat, 11 Nov 2017 22:26:41 +0000

No wonder people complain about Apple being expensive — having to take it in for servicing every time the mouse battery runs low must add up fast!

An open USB "firewall" is apparently available

Herve5 — Sat, 11 Nov 2017 18:26:35 +0000

I suspect I am quite alone in my geographical area reading LWN, but just in case : if some neigbors in the French Maritime alps (06xx postal code here) wish to join I'd definitely share the shipping costs for a small series of these devices...
Potentially extendable to other areas with family/friends regularly, but not hurriedly visited : french cities of Toulouse and Paris.
I'll come back here in a couple of days to check ;-)
H.

USBGuard: authorization for USB

juliank — Fri, 10 Nov 2017 20:27:08 +0000

In theory, yes. In practice, there are probably devices using them and people relying on them :)

USBGuard: authorization for USB

TheLessThanAmazing — Fri, 10 Nov 2017 01:15:24 +0000

Don't forget that a single USB device can have multiple pipes/endpoints.

USBGuard: authorization for USB

gdt — Thu, 09 Nov 2017 23:00:50 +0000

As an aside, there are USB Product IDs for documentation such as the book you reference, namely 0x1d50:0x5200 through to 0x1d50:0x52ff. Distributions can safely suppress any device offering a Product ID within that range.

Locking your keys inside

tzafrir — Thu, 09 Nov 2017 22:24:57 +0000

Now start typing a PIN with your mouse.

Locking your keys inside

flussence — Thu, 09 Nov 2017 20:58:29 +0000

This is a solved problem: just copy what Bluetooth does with PIN codes.

USBGuard: authorization for USB

nix — Thu, 09 Nov 2017 15:51:51 +0000

Also, as of a few days ago it appears that Skylake and later systems can have the ME rooted via JTAG over the USB ports. Since the CPU never sees it (heck, it doesn't even use the USB protocol), and the rooted ME can do *anything*, this seems like a good vector for truly horrific evil maid attacks.

(Thank goodness it requires physical access.)

USBGuard: authorization for USB

mfuzzey — Thu, 09 Nov 2017 11:36:03 +0000

As I understand it this is not quite true.

Hubs do broadcast all data coming from the upstream (host) to all the downstream devices.

But data from the downstream devices is only sent to the upstream host.

So, if you plug a keyboard, a USB stick and a rogue device into the same hub they rogue device couldn't read they keystrokes (because they are going in the wrong direction) but it could read the data being written to (but not read from) the USB stick.

USBGuard: authorization for USB

grawity — Thu, 09 Nov 2017 10:33:48 +0000

Yes, you could use udev rules to do this by setting ATTR{authorized} apropriately – but they need to be written, while USBGuard has more convenient UIs for that (both command-line and graphical) – a notification pops up and you can confirm the device temporarily or permanently. That's something the article has forgotten to mention.

Since y'all have already started making fun of people being inconvenienced by this feature, it would be unfair to tell the same people to edit udev rulesets every time they get a new device.

Regarding kernel versions, per-device authorization was added in 2007, somewhere around v2.6.24. Per-interface (more fine-grained) authorization is a 2015 addition in v4.4.

USBGuard: authorization for USB

mjthayer — Thu, 09 Nov 2017 09:17:39 +0000

It should even theoretically be possible, if you build the data bases, to present the user of a picture of their computer with diagrams showing what is plugged in where (at least for laptops and other standard-ish systems). If the user knows they wanted to plug a network device into such and such a port they can click on the picture of it to white list it. Agreed that input devices should probably get special treatment.

An open USB "firewall" is apparently available

bokr — Thu, 09 Nov 2017 04:52:50 +0000

http://hexus.net/tech/news/peripherals/103132-the-usg-don...

Presumably some fruit-pi device with OTG could be programmed to do something similar,
and maybe blink some red leds and provide a trace of attempted bad stuff for access
via ssh from either side, or third connection -- eth, wifi, bt ? -- there's a lot of connection
options in the fruit-pi world, it would seem.

I like the idea of having a physical device that I can trust between computer and usb device,
whichever side I am the owner of and want to protect.

USBGuard: authorization for USB

unixbhaskar — Thu, 09 Nov 2017 03:45:09 +0000

Yup, that is my query too! ..thanks for bringing up.

USBGuard: authorization for USB

biergaizi — Thu, 09 Nov 2017 02:48:49 +0000

> allow 1050:0011 name "Yubico Yubikey II"

What's the point here? USB Vendor and Device IDs can be claimed by any re-programmable USB devices, and Vendor ID abuse is a widespread problem. If I remembered correctly, the Vendor ID of a Linux developer who had written an USB programming book, was abused by many clueless manufacturers. And now the Free Software Initiative of Japan, the organization behind Gnuk, the open implementation of OpenPGP smartcard on general microcontrollers, was trying to prevent it from happening again by integrating a Vendor ID setting into the Gnuk build system, and adding warnings about not using FSIJ's Vendor ID on customized Gnuk tokens.

If an attacker is going to infiltrate one physically, I assume they will do their homework to figure it out. Or the whole scheme requires one to keep the USB Vendor/Device ID and its serial number as a secret? Sounds reasonable, and it can make many attacks difficult. But I'm still uncomfortable as it's not possible to keep the serial number of my USB thumb drive as a secret.

USBGuard: authorization for USB

rahvin — Thu, 09 Nov 2017 01:38:14 +0000

I'm not sure how that would be worse than a USB thumb drive that reports itself as a storage device, keyboard, mouse and network controller along with some handy malware that autoruns, draws it's own IP address, opens a vpn connection and starts logging all input/ouput while scanning all attached storage.

USBGuard: authorization for USB

tialaramex — Thu, 09 Nov 2017 00:54:19 +0000

But the internal peripherals will be plugged in to a different part of the topology. So it's possible to write a rule that says OK, you can have this device on this internal port, where it would be if it's built-in, but it's not allowed on the external USB ports because that makes no sense.

USBGuard: authorization for USB

Cyberax — Thu, 09 Nov 2017 00:49:34 +0000

Can't you do it only with udev rules?

USBGuard: authorization for USB

chfisher — Thu, 09 Nov 2017 00:39:12 +0000

Which version of the kernel is required to support this? - none of the documentation says

USBGuard: authorization for USB

tialaramex — Thu, 09 Nov 2017 00:36:15 +0000

Well, without having yet spent much time thinking about the practical capabilities, I will say that this _is_ equivalent to the lock down required in many enterprise employee systems.

Typically their rule is you can plug in any input device (so the employee's own keyboard works, as does some generic USB mouse they borrowed at a conference when theirs broke) and thus filling the sockets with epoxy is not an option - but it won't allow say, a USB thumb drive. You also see rules prohibiting USB network devices, web cams, and I've even seen printers.

In each case the intent is not to prevent bad guys from doing things, but as a nudge reminder for good guys. Company policy says they mustn't put data onto USB thumb drives. But such a policy might get bent and eventually broken by normal corner cutting. Policy enforcement means that temptation is avoided. A sophisticated employee could probably bypass the protection somehow, but that's _more_ hassle than accepting the policy and not using the drives.

It's usually the case that such a corporate policy can grant exceptions for special purposes. We can imagine that a company with a rule against web cams might decide that a home worker needs a web cam to join video conferences that in the company's own offices are held using a dedicated system, because delivering such a system to the home worker is excessively expensive. Or there might be cause for a technician to have working USB thumb drives despite everybody else up to the executive floor being forbidden. USBGuard seems appropriately flexible.

USBGuard: authorization for USB

ballombe — Wed, 08 Nov 2017 22:38:54 +0000

Also there are no reasonable way to identify most devices.
It is easy to impersonate a standard Dell keyboard.
It is not uncommon for laptop to have internal peripherals plugged to the USB bus that could also being impersonated.

USBGuard: authorization for USB

dullfire — Wed, 08 Nov 2017 21:51:14 +0000

Something to note: there are exceptions but in general usb devices receive, at an electrical level, all the data the host sends to any device on the same usb bus (USB 3 sort of changes this, and usb devices operating at different speeds don't see the same traffic). So to some degree a usb device can "passively", after it's been enumerated onto the bus, listen to bus traffic. And if the attacker has physical access, the could simply unplug each device and it's descriptors, in a attempt to build a table of permutations to try (of course being port lock is a little better protection).
While I think attempting to secure USB is a worth while endeavor, it does not seem, to me personally, from this article that USBGuard gives significant protection compared to the effort to configure and the inconvenience when things break.

USBGuard: authorization for USB

ejr — Wed, 08 Nov 2017 20:27:28 +0000

The most insidious USB threats are outside OS control. The microcontrollers on both sides are vulnerable before anything reaches the OS. I'm not saying the proposed framework is bad, just that it's limited to aspects that *are* under OS control.

Locking your keys inside

abatters — Wed, 08 Nov 2017 17:05:03 +0000

Scenario:
Whitelist your existing USB devices.
Existing USB keyboard stops working.
Go to store and buy a new keyboard.
Plug in new keyboard.
New keyboard isn't whitelisted, so can't use it to login to add it to the whitelist.

What you need then is some variant of the well-known "port knocking" technique from the network world, where you plug and unplug the new device into a specific series of ports with specific timings known only to you to add it to the whitelist automatically. Maybe to the tune of your favorite song?

Sorry, couldn't help myself.

;-)