2

I would like to know, if assuming I attach an untrusted device (via usb port to my system), how much do I put my Linux system at risk? In particular, I am worried that even though I would write udev rules to block anything but (i.e. whitelist approach) a certain device, that the kernel would be vulnerable anyway?

Does udev have the capacity to prevent the kernel (assuming it is modular) from loading modules that would normally be loaded as a way to interact with an usb device?

4

The kernel has the ability to protect itself from USB devices, using the USB authorization framework. You can disable all hosts at boot:

for host in /sys/bus/usb/devices/usb*
do
    echo 0 > $host/authorized_default
done

or even disable authorization altogether, before devices are processed, by passing usbcore.authorized_default=0 on the kernel command line (just make sure your udev rules enable any USB device you need to boot, such as your keyboard).

Once that’s done, connecting a USB device won’t load any new modules or create any new devices. To enable a new USB device, you’ll have to manually authorize it, then trigger driver probing manually (see the documentation for details).

  • Wow that is super! and will allow to add another layer of protection, no need to have a fake usb stick acting like a keyboard (with all the risks associated) on my box. Anyway I assume with intel ME being there and attackable, I have now a safe ring 0 and a intelME unsafe ring -3. great! securityaffairs.co/wordpress/65327/hacking/… – humanityANDpeace Dec 21 '17 at 11:07
  • The example in the documentation shows a script triggered by udev. This script temporarily authorizes and mounts the device and then de-authorizes it again unless the device can provide an access key. Doesn't authorizing the unknown device even for a second already open up your computer to attack? – GroovyDotCom Jul 24 '18 at 9:22
  • 1
    Yes, @Groovy, the example in the documentation isn’t very good, but it’s eleven years old. You’d be better off using something like USBGuard. – Stephen Kitt Jul 24 '18 at 13:42
  • @StephenKitt but even that 11 year old documentation says "Just checking if the class, type and protocol match something is the worse security verification you can make..." which is exactly what USBGuard seems to be doing? Sounds like a catch 22. Before you authorize it, the only things you can check are class,type,protocol which can be faked and after you authorize it, you open yourself up to attack. – GroovyDotCom Jul 24 '18 at 18:23
  • 1
    @Groovy right. I recommend USBGuard because it encourages interactivity; the scenario I really care about is what happens when someone connects a USB device to one of my computers when I’m not present. With the script from the docs, systems are vulnerable; with USBGuard set up to always ask, they’re not. There’s no good answer for how to deal with devices that you do want to use (short of using a dedicated quarantine system). – Stephen Kitt Jul 24 '18 at 19:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.