Protect against BadUSB device

[Pierre van Male]

During the last months, it appeared that the theoretical threat of a compromised USB device acting as keyboard became a real possibility: https://srlabs.de/badusb.

The solution against such threat is simply to ask the user the confirmation before binding a new USB device as keyboard and a solution was already documented: http://vogelchr.blogspot.in/2014/08/controlling-usb-device-access-on-linux.html

Similar solution already exist for MS Windows: http://robert.penz.name/930/protect-your-pc-against-the-badusb-attack-on-linux-and-windows

Even though the probability to get a compromised USB device is low, the security threat is serious and since the solution is simple, Ubuntu should be protected properly asap.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: udev 204-5ubuntu20.8
ProcVersionSignature: Ubuntu 3.13.0-39.66-generic 3.13.11.8
Uname: Linux 3.13.0-39-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.5
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Nov 18 02:48:36 2014
EcryptfsInUse: Yes
InstallationDate: Installed on 2014-08-25 (84 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64+mac (20140417)
MachineType: LENOVO 4298RD9
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-39-generic root=UUID=fa0ba264-7e15-48e1-89e6-3c88237a1903 ro persistent quiet splash vt.handoff=7
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/07/2011
dmi.bios.vendor: LENOVO
dmi.bios.version: 8DET50WW (1.20 )
dmi.board.asset.tag: Not Available
dmi.board.name: 4298RD9
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr8DET50WW(1.20):bd07/07/2011:svnLENOVO:pn4298RD9:pvrThinkPadX220Tablet:rvnLENOVO:rn4298RD9:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 4298RD9
dmi.product.version: ThinkPad X220 Tablet
dmi.sys.vendor: LENOVO

[Seth Arnold (seth-arnold)]

Sadly, the solution is not easy nor obvious. Ubuntu is used in a wide variety of different ways and many of them do not lend themselves well to just popping up a dialog box.

Furthermore, the problem is not at all restricted to just devices that can be reprogrammed to act like keyboards.

A fairly lengthy discussion can be found here: http://www.openwall.com/lists/oss-security/2014/08/09/4

Thanks

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Pierre van Male (vmalep)]

@ Seth Arnold: Thanks for your comment. In the case of an USB device acting as a keyboard and for multi-seat machines or remote servers, the keyboard should simply not be activated (what for?). This security measure can also be an option available in "Security & Privacy". I agree that Ubuntu and GNU/Linux is used in many different configuration and the solution proposed here is mostly for desktop use, but it still make sense.

[Martin Pitt (pitti)]

Removing package for now, as it's not at all clear how to design this (at least udev is way too low in the stack to even potentially ask the user anything).

I'm very sceptical of these approaches. Experience shows that popping up dialog boxes with security related questions à la "are you sure that ..." are at least annoying and rarely productive. And on a server you usually don't even have a way to interactively ask the user anything on hardware changes.

If there is a way to detect "malicious" USB devices in some way, we absolutely should do that, but as versatile as they are, USB devices can do pretty much anything. They could act as an audio device to record what you are doing, as a network device to re-route traffic, or as a malicious keyboard (but that's not even the worst IMHO, as you then usually see that something funky is going on and yank it out again).

It's nothing new at all that malicious hardware can exist and that hardware always trumps software in terms of trying to keep each other in check :-)

[Martin Pitt (pitti)]

For the cases of having a multi-function device which also acts as a keyboard we could potentially ask whether the user really wants to use it. This just needs to keep in mind that there are many legitimate devices which look very similar -- headsets often have buttons (which manifest as evdev devices, i. e. similar to keyboards, but you can tell them apart via their event mask), or Yubikeys which are legitimately USB keyboards to enter passwords, etc. -- These dialog boxes must have a very low false positive ratio, or people will quickly start ignoring them just like they get conditioned to ignore pretty much every other security dialog (policykit, Firefox untrusted certificates, and what not).

[asgard2 (kamp000x)]

I am worried about this too, because there is no protection.
Could imagine that when inserting a new stick or a keyboard only a short query with the device type needs to be confirmed. This request can be omitted by known devices.
This is maybe annoying, but safety first!

[johnmne (phi-reporter)]

I opened a duplicate thread, in the following link:
https://bugs.launchpad.net/ubuntu/+bug/1590990

The user "Seth Arnold" asked my several questions and I replied to them all.
Here are my answers to his questions:

----------------------------------------

"- How would a user interact when plugging in the first keyboard or mouse?"
The first keyboard and mouse are normally connected when powering on the PC.
The behaviour should be like today - no restrictions for the first keyboard and mouse.
(Normally the USB flash drive is connected only *after* that the normal keyboard & mouse are already connected.)

"- What if the malicious device was first only because it was 'earlier' in the USB network?"
If by "earlier in the USB network" you mean :
 * "connected before the keyboard and mouse" then for now there is not much I can think of. But normally that does not happen, and *some* protection is better than none.
 * "connected in parallel (same time) to keyboard & mouse" then alert the user that he needs to remove one of them in order to proceed.

"- How would the system tell a keyboard-with-hub that a user intended to buy from a keyboard-with-hub that a user didn't intend to buy?"
Hubs aren't the norm.
In case that someone has a hub (doubtful..) then he can always disable the security behaviour. I sincerely believe that most of the people would prefer to have more protection and little discomfort than having this huge exploit.

"- What would the interaction look like on a computer with no displays? With a dozen displays? With a dozen seats?"
With no displays: Does it connect via ssh? If so, then he could see the message. If not then a sound/beep would be activated. If having no speakers then the user should understand that something is wrong... But I think that this is rarely happen, therefore if it does happen - then it is probably(??) the USB exploit.
With dozen of displays: Simply display an alert window of some sort on one of the desktop (is this really a problem? How does Ubuntu manages to display errors with dozen of displays?).
With a dozen seats: What do you mean by "seats" ?

USB is very flexible indeed, but most people would prefer to know that their system is secure than spending few minutes (or half an hour in worst case) in understanding the (rare) problem and fixing it.

----------------------------------------

This security feature, that protects against badUSB, should be *DISABLED* by default.
BUT the user should have the option to easily enable the feature - this makes sure that the user is aware of the problems that could arose due to the security feature.

Even if this security feature is implemented in the most simplistic approach - by disabling/prompting for all keyboard & mouse devices which are connected after an existing keyboard & mouse - then it will protect from *most* of the badUSB attacks.

Please do note that Windows already has a protection against badUSB. ("why not linux?")