Allow userspace control of runtime disabling/enabling of driver probing

From: Matthew Garrett <[email protected]>

Various attacks are made possible due to the large attack surface of kernel drivers and the easy availability of hotpluggable hardware that can be programmed to mimic arbitrary devices. This allows attackers to find a single vulnerable driver and then produce a device that can exploit it by plugging into a hotpluggable bus (such as PCI or USB). This violates user assumptions about unattended systems being secure as long as the screen is locked.

The kernel already has support for deferring driver binding in order to avoid problems over suspend/resume. By exposing this to userspace we can disable probing when the screen is locked and simply reenable it on unlock.

This is not a complete solution - since this still permits device creation and simply blocks driver binding, it won't stop userspace drivers from attaching to devices and it won't protect against any kernel vulnerabilities in the core bus code. However, it should be sufficient to block attacks like Poisontap (https://samy.pl/poisontap/).

Quoted 15 lines · Kees Cook

From: Matthew Garrett <[email protected]>

Various attacks are made possible due to the large attack surface of kernel drivers and the easy availability of hotpluggable hardware that can be programmed to mimic arbitrary devices. This allows attackers to find a single vulnerable driver and then produce a device that can exploit it by plugging into a hotpluggable bus (such as PCI or USB). This violates user assumptions about unattended systems being secure as long as the screen is locked.

The kernel already has support for deferring driver binding in order to avoid problems over suspend/resume. By exposing this to userspace we can disable probing when the screen is locked and simply reenable it on unlock.

Quoted 5 lines

This is not a complete solution - since this still permits device creation and simply blocks driver binding, it won't stop userspace drivers from attaching to devices and it won't protect against any kernel vulnerabilities in the core bus code. However, it should be sufficient to block attacks like Poisontap (https://samy.pl/poisontap/).

It also looks like this may be worked around by tricking the user to unlock the screen while the malicious device is still attached to the system.

If that really is the case, I wonder if it's worth the extra complexity.

Quoted 22 lines · Rafael J. Wysocki

Quoted 20 lines · Kees Cook

From: Matthew Garrett <[email protected]>

Various attacks are made possible due to the large attack surface of kernel drivers and the easy availability of hotpluggable hardware that can be programmed to mimic arbitrary devices. This allows attackers to find a single vulnerable driver and then produce a device that can exploit it by plugging into a hotpluggable bus (such as PCI or USB). This violates user assumptions about unattended systems being secure as long as the screen is locked.

The kernel already has support for deferring driver binding in order to avoid problems over suspend/resume. By exposing this to userspace we can disable probing when the screen is locked and simply reenable it on unlock.

This is not a complete solution - since this still permits device creation and simply blocks driver binding, it won't stop userspace drivers from attaching to devices and it won't protect against any kernel vulnerabilities in the core bus code. However, it should be sufficient to block attacks like Poisontap (https://samy.pl/poisontap/).

Quoted 3 lines

It also looks like this may be worked around by tricking the user to unlock the screen while the malicious device is still attached to the system.

It certainly changes the temporal aspect of the attack (i.e. there is a delay and must be "silent" in that the local user cannot notice it).

Quoted 1 line

If that really is the case, I wonder if it's worth the extra complexity.

I think so, since it's not that much more complexity (it uses the existing deferral mechanism).

From: Matthew Garrett <[email protected]>

Various attacks are made possible due to the large attack surface of kernel drivers and the easy availability of hotpluggable hardware that can be programmed to mimic arbitrary devices. This allows attackers to find a single vulnerable driver and then produce a device that can exploit it by plugging into a hotpluggable bus (such as PCI or USB). This violates user assumptions about unattended systems being secure as long as the screen is locked.

The kernel already has support for deferring driver binding in order to avoid problems over suspend/resume. By exposing this to userspace we can disable probing when the screen is locked and simply reenable it on unlock.

This is not a complete solution - since this still permits device creation and simply blocks driver binding, it won't stop userspace drivers from attaching to devices and it won't protect against any kernel vulnerabilities in the core bus code. However, it should be sufficient to block attacks like Poisontap (https://samy.pl/poisontap/).

Signed-off-by Matthew Garrett <[email protected]>

Signed-off-by Kees Cook <[email protected]>

---
 .../ABI/testing/sysfs-kernel-disable-device-probe  | 10 ++++++++
 drivers/base/base.h                                |  2 --
 drivers/base/dd.c                                  | 10 ++++++++
 drivers/base/power/main.c                          | 16 ++++++++++---
 include/linux/device.h                             |  4 ++++
 kernel/ksysfs.c                                    | 28 ++++++++++++++++++++++
 6 files changed, 65 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-kernel-disable-device-probe

Documentation/ABI/testing/sysfs-kernel-disable-device-probe new file +10 -0

new file mode 100644
index 000000000000..1ca6c2d11d8b
@@ -0,0 +1,10 @@
+What:		/sys/kernel/disable_device_probe
+Date:		December 2016
+KernelVersion:	4.11
+Contact:	Matthew Garrett <[email protected]>
+Description
+		Disables automatic driver probing of any newly added devices.
+		If "1", driver probing is disabled - any newly added devices
+		will not have a driver bound to them. If "0", newly added
+		devices will be probed, along with any devices connected while
+		"1" was set.

drivers/base/base.h +0 -2

index ada9dce34e6d..7bee2e4e38ce 100644
@@ -134,8 +134,6 @@ extern void device_remove_groups(struct device *dev,
 extern char *make_class_name(const char *name, struct kobject *kobj);
 
 extern int devres_release_all(struct device *dev);
-extern void device_block_probing(void);
-extern void device_unblock_probing(void);
 
 /* /sys/devices directory */
 extern struct kset *devices_kset;

drivers/base/dd.c +10 -0

index a8b258e5407b..4d70fa41132c 100644
@@ -191,6 +191,16 @@ static void driver_deferred_probe_trigger(void)
 }
 
 /**
+ * device_probing_deferred() - Get the current state of device probing
+ *
+ *	Returns whether or not device probing is currently deferred
+ */
+bool device_probing_deferred(void)
+{
+	return defer_all_probes;
+}
+
+/**
  * device_block_probing() - Block/defere device's probes
  *
  *	It will disable probing of devices and defer their probes instead.

drivers/base/power/main.c +2 -0

index 249e0304597f..b566e7a6140c 100644
@@ -59,6 +59,8 @@ struct suspend_stats suspend_stats;
 static DEFINE_MUTEX(dpm_list_mtx);
 static pm_message_t pm_transition;
 
+static bool probing_deferred;
+
 static int async_error;
 
 static char *pm_verb(int event)

@@ -1024,8 +1026,12 @@ void dpm_complete(pm_message_t state)
 	list_splice(&list, &dpm_list);

Ick, hiding this in the power management code? That's messy, and complex, as Rafael pointed out.

Turning on and off at random times "new devices can not be bound, wait, now they can!" is ripe for loads of issues and is going to be a pain to properly maintain over time.

What's wrong with the facility that the USB layer provides today to allow only "authenticated" devices to be enabled? That has been used for a few years now to prevent these "don't allow random devices that are plugged into the computer to be enabled" type attacks. Doing much the same thing, in a different manner, is ripe for problems (how do the two interact now?)

If you are worried about PCI devices, why not just implement what USB did for PCI? Or better yet, move the USB functionality into the driver core, adding that type of authentication ability to any bus that wishes to have it (and not break existing working systems that are using the USB solution today.)

The USB authentication feature was intended for handling wireless USB devices - it can be reused for this, but the code isn't generic enough to apply to other bus types. The two interact in exactly the way you'd expect, ie they don't. If you use both, then you need to handle both.

Quoted 5 lines · Matthew Garrett

The USB authentication feature was intended for handling wireless USB devices - it can be reused for this, but the code isn't generic enough to apply to other bus types. The two interact in exactly the way you'd expect, ie they don't. If you use both, then you need to handle both.

And as an example of why the USB authorisation feature isn't sufficient - the interface configuration isn't picked until after you've authorised the device, which means you can't necessarily tell the difference between a keyboard and an ethernet adapter until after you've authorised it.

That defeats the object, but it can't be changed without breaking the wireless USB case.

You know the device type and vendor/product id before you authorize it, you should be able to do this type of detection otherwise it seems pretty pointless :)

Quoted 3 lines · Greg Kroah-Hartman

You know the device type and vendor/product id before you authorize it, you should be able to do this type of detection otherwise it seems pretty pointless :)

You know the vendor and product ID, which doesn't tell you whether one of the endpoints is a network device or a keyboard. You need to know that.

Quoted 3 lines · Greg Kroah-Hartman

You know the device type and vendor/product id before you authorize it, you should be able to do this type of detection otherwise it seems pretty pointless :)

You know the vendor and product ID, which doesn't tell you whether one of the endpoints is a network device or a keyboard. You need to know that.

Quoted 6 lines · Matthew Garrett

Quoted 3 lines · Greg Kroah-Hartman

You know the device type and vendor/product id before you authorize it, you should be able to do this type of detection otherwise it seems pretty pointless :)

Quoted 3 lines

You know the vendor and product ID, which doesn't tell you whether one of the endpoints is a network device or a keyboard. You need to know that.

Are you sure you don't have the configuration information as well? That should tell you...

And for network devices, they are almost all just vendor/product ids, not many use the class protocol.

usb_choose_configuration() hasn't been called at this point, so no - we don't create any device entries, so there's no way for userspace to know anything (there isn't even a uevent on device plug). And even if you could scrape the info, you still have no way of knowing what configuration the kernel will choose if the device has multiple.

Quoted 2 lines · Greg Kroah-Hartman

Ick, hiding this in the power management code? That's messy, and complex, as Rafael pointed out.

It's in code that's used in the power management layer, not in power management code. This is all in the driver core.

Quoted 3 lines

Turning on and off at random times "new devices can not be bound, wait, now they can!" is ripe for loads of issues and is going to be a pain to properly maintain over time.

What kind of issues?

Quoted 6 lines

What's wrong with the facility that the USB layer provides today to allow only "authenticated" devices to be enabled? That has been used for a few years now to prevent these "don't allow random devices that are plugged into the computer to be enabled" type attacks. Doing much the same thing, in a different manner, is ripe for problems (how do the two interact now?)

The USB authentication feature was intended for handling wireless USB devices - it can be reused for this, but the code isn't generic enough to apply to other bus types. The two interact in exactly the way you'd expect, ie they don't. If you use both, then you need to handle both.

Quoted 5 lines

If you are worried about PCI devices, why not just implement what USB did for PCI? Or better yet, move the USB functionality into the driver core, adding that type of authentication ability to any bus that wishes to have it (and not break existing working systems that are using the USB solution today.)

The USB approach requires userspace to keep track of which devices were added while the session was locked, whereas the kernel already has the logic to do all of this. All the complexity already exists and is used every time anybody suspends and resumes, so why add additional complexity?

I'm not clear on how this patch breaks anybody using the existing USB solution?

Quoted 7 lines · Matthew Garrett

Quoted 2 lines · Greg Kroah-Hartman

Ick, hiding this in the power management code? That's messy, and complex, as Rafael pointed out.

It's in code that's used in the power management layer, not in power management code. This is all in the driver core.

Yes, but it's in the power management layer, not the "main" portion of the driver bind/unbind logic. It's kind of hidden, don't you think?

Quoted 5 lines

Quoted 3 lines

Turning on and off at random times "new devices can not be bound, wait, now they can!" is ripe for loads of issues and is going to be a pain to properly maintain over time.

What kind of issues?

How are you going to test this to ensure it continues to work properly?

Quoted 7 lines

Quoted 6 lines

What's wrong with the facility that the USB layer provides today to allow only "authenticated" devices to be enabled? That has been used for a few years now to prevent these "don't allow random devices that are plugged into the computer to be enabled" type attacks. Doing much the same thing, in a different manner, is ripe for problems (how do the two interact now?)

Quoted 4 lines

The USB authentication feature was intended for handling wireless USB devices - it can be reused for this, but the code isn't generic enough to apply to other bus types. The two interact in exactly the way you'd expect, ie they don't. If you use both, then you need to handle both.

The feature was originally created for wireless USB devices, but it will work for any USB device, and has been successfully used for this type of thing (i.e. protecting kiosk-systems) for a while now.

Quoted 11 lines

Quoted 5 lines

If you are worried about PCI devices, why not just implement what USB did for PCI? Or better yet, move the USB functionality into the driver core, adding that type of authentication ability to any bus that wishes to have it (and not break existing working systems that are using the USB solution today.)

The USB approach requires userspace to keep track of which devices were added while the session was locked, whereas the kernel already has the logic to do all of this. All the complexity already exists and is used every time anybody suspends and resumes, so why add additional complexity?

The kernel knows nothing about a "session", you know that. Userspace can disable enabling any new USB device when a session is "locked" today quite easily, why not do that?

Quoted 2 lines

I'm not clear on how this patch breaks anybody using the existing USB solution?

You now have two different ways to enable access to a USB device, please let's keep to only one type of path.

Quoted 7 lines · Greg Kroah-Hartman

Quoted 6 lines · Matthew Garrett

Quoted 3 lines · Greg Kroah-Hartman

Turning on and off at random times "new devices can not be bound, wait, now they can!" is ripe for loads of issues and is going to be a pain to properly maintain over time.

Quoted 3 lines

Quoted 1 line

What kind of issues?

How are you going to test this to ensure it continues to work properly?

It's code that's already used over every suspend and resume. What kind of breakage are you expecting? How do we test any feature to ensure it continues to work properly?