5 ms·

Can't this be solved in the host OS? USB devices have a vendor and product id (VID, PID) and a device class (HID class [1]). I'm not sure why the operating syst

Can't this be solved in the host OS? USB devices have a vendor and product id (VID, PID) and a device class (HID class [1]). I'm not sure why the operating system couldn't keep track of which ones are authorized. It could also allow whitelisting of certain HID classes (eg "allow all mice"). If the HID changes, it would prompt for authorization again, which would mitigate an entire class of attacks ("BAD USB"). It would still allow someone to bypass the authentication if they know the VID and PID of something already authorized with the desired HID class, but that seems reasonable and is significantly better than what we have today. Are there any systems that work like this today, and if not, is there a reason? [1] https://en.m.wikipedia.org/wiki/USB_human_interface_device_class https://en.m.wikipedia.org/wiki/USB_human_interface_device_c...

NullPrefix 8y ago
How are you going to authorize new HID devices without other currently working and authorized HID devices?
wpowiertowski 8y ago
Exactly why cryptographic authentication is required. There are fuzzing devices today that present themselves as known VID/PID/HID combinations that have generic drivers in modern OS's and can exploit that. One of the primary drivers for this is the power delivery - imagine a scenario where you have authentic power brick and laptop and buy a counterfeit USB-PD cable, power brick sends 100W over it and it results in the cable melting since it was really a $5 knock-off and you end up with a fried USB-C port in your laptop and possibly a fire. I'm sure most people would wish that the power-brick/laptop checked that cable is genuine and build to handle the power.
- deleted 8y ago
  [deleted]
- phil21 8y ago
  That seems like a very weak failsafe likely to be easily cracked and those bad actors only slowed down a bit - if history is any guide. Why not implement something like detecting voltage drop between charger and device? Short circuit detection, etc. You can do a lot if you can have both sides communicate with each other, and at that point it matters a whole lot less if your cable lies to you plus you catch a lot of other failure conditions.
  - wpowiertowski 8y ago
    There are more use cases where being able to prove cryptographically the identity of the device is very useful from security point of view, PD is simply one of them.
  - metaphor 8y ago
    Apparently, BC 1.2 spec verbiage suggests this is already a hard requirement: The OTG device is required to limit the current it draws from the ACA such that VBUS_OTG remains above Vaca_opr min.
- metaphor 8y ago
  > One of the primary drivers for this is the power delivery - imagine a scenario... Not a USB engineer, but a quick peek at the BC 1.2 spec suggests the ball would have to be dropped on at least two additional fronts for the suggested failure mode to occur: 1.) The Charging Port device vendor for failing to implement any of the allowed shutdown measures suggested in BC1.2 §4.1.4; and 2.) the Downstream Port device vendor for failing to constrain current draw based on sensed Vaca_opr min = 4.1V (Table V) per ibid. §§6.2.2 and 6.3.1. I can see how the knock-off cable would be toast, and depending on insulation rating, may potentially catch fire, but struggle to see how either the CP or DP USB-C ports would fry (considering they're both designed for a target power).
- Dylan16807 8y ago
  USB-PD only raises the limit from 3 amps to 5. It doesn't increase the risk of fire very much at all, even in a counterfeit cable.
geofft 8y ago
That would work somewhat—VID/PID can't be trusted but device class can be. But the problem is that on e.g. my MacBook with a single USB C port, sometimes I want to use a keyboard (either an actual keyboard or a YubiKey) and sometimes I don't (if I'm charging). If I plug in a hub I want to trust my hub but not someone else's device claiming to be a hub. And so forth. Having a charging-only-by-default port would be a 90% solution, but would be very annoying for people who need to reauthorize a device every time they plug it in, which is why I think pairing is better. And I'm not sure what devices you can reasonably trust other than pure power. HID is definitely out for fear of Rubber Ducky-style attacks. External video adapters can read your screen. Headphones can listen in on calls. Thumbdrives / PTP devices might be safe if handled carefully but are kind of the classic worry, so I'm not sure if people will want those. Maybe pure U2F devices, webcams, and audio input devices? Not sure how useful or user-friendly such a restriction would be.
- gregmac 8y ago
  I guess what I'm picturing is the first time you plug in your keyboard/Yubikey/whatever, your system prompts you "A new device 'AcmeCo USB Keyboard' (VID=xxxx/PID=xxxx) wants to provide service(s): Keyboard Input. Allow? Once/Always/No/Never." After that, your system saves that combination, and assuming you authorized it permanently, whenever you plug in that VID/PID, it has access to be a keyboard. If it tries to present another HID later, that would result in a new prompt, the same as a brand new device. If it changes HID while plugged in, that could even be a more severe message along the lines of "Hey, this keyboard just tried to become a video adapter and thumb drive, that's really suspicious and you should probably destroy it with fire". Likewise, VID/PID changing without being unplugged/replugged in, changing too quickly, or even just after too many new VID/PIDs in a short time period should result in a temporary lockdown -- in the same way fail2ban blocks repeated login attempts from a given IP.
  - geofft 8y ago
    What prevents a malicious device from pretending to be a common model of keyboard (say the most common Apple or Dell one)?

NullPrefix 8y ago

How are you going to authorize new HID devices without other currently working and authorized HID devices?

wpowiertowski 8y ago

Exactly why cryptographic authentication is required. There are fuzzing devices today that present themselves as known VID/PID/HID combinations that have generic drivers in modern OS's and can exploit that. One of the primary drivers for this is the power delivery - imagine a scenario where you have authentic power brick and laptop and buy a counterfeit USB-PD cable, power brick sends 100W over it and it results in the cable melting since it was really a $5 knock-off and you end up with a fried USB-C port in your laptop and possibly a fire. I'm sure most people would wish that the power-brick/laptop checked that cable is genuine and build to handle the power.

deleted 8y ago
[deleted]
phil21 8y ago
That seems like a very weak failsafe likely to be easily cracked and those bad actors only slowed down a bit - if history is any guide. Why not implement something like detecting voltage drop between charger and device? Short circuit detection, etc. You can do a lot if you can have both sides communicate with each other, and at that point it matters a whole lot less if your cable lies to you plus you catch a lot of other failure conditions.
- wpowiertowski 8y ago
  There are more use cases where being able to prove cryptographically the identity of the device is very useful from security point of view, PD is simply one of them.
- metaphor 8y ago
  Apparently, BC 1.2 spec verbiage suggests this is already a hard requirement: The OTG device is required to limit the current it draws from the ACA such that VBUS_OTG remains above Vaca_opr min.
metaphor 8y ago
> One of the primary drivers for this is the power delivery - imagine a scenario... Not a USB engineer, but a quick peek at the BC 1.2 spec suggests the ball would have to be dropped on at least two additional fronts for the suggested failure mode to occur: 1.) The Charging Port device vendor for failing to implement any of the allowed shutdown measures suggested in BC1.2 §4.1.4; and 2.) the Downstream Port device vendor for failing to constrain current draw based on sensed Vaca_opr min = 4.1V (Table V) per ibid. §§6.2.2 and 6.3.1. I can see how the knock-off cable would be toast, and depending on insulation rating, may potentially catch fire, but struggle to see how either the CP or DP USB-C ports would fry (considering they're both designed for a target power).
Dylan16807 8y ago
USB-PD only raises the limit from 3 amps to 5. It doesn't increase the risk of fire very much at all, even in a counterfeit cable.

geofft 8y ago

That would work somewhat—VID/PID can't be trusted but device class can be. But the problem is that on e.g. my MacBook with a single USB C port, sometimes I want to use a keyboard (either an actual keyboard or a YubiKey) and sometimes I don't (if I'm charging). If I plug in a hub I want to trust my hub but not someone else's device claiming to be a hub. And so forth. Having a charging-only-by-default port would be a 90% solution, but would be very annoying for people who need to reauthorize a device every time they plug it in, which is why I think pairing is better. And I'm not sure what devices you can reasonably trust other than pure power. HID is definitely out for fear of Rubber Ducky-style attacks. External video adapters can read your screen. Headphones can listen in on calls. Thumbdrives / PTP devices might be safe if handled carefully but are kind of the classic worry, so I'm not sure if people will want those. Maybe pure U2F devices, webcams, and audio input devices? Not sure how useful or user-friendly such a restriction would be.

gregmac 8y ago
I guess what I'm picturing is the first time you plug in your keyboard/Yubikey/whatever, your system prompts you "A new device 'AcmeCo USB Keyboard' (VID=xxxx/PID=xxxx) wants to provide service(s): Keyboard Input. Allow? Once/Always/No/Never." After that, your system saves that combination, and assuming you authorized it permanently, whenever you plug in that VID/PID, it has access to be a keyboard. If it tries to present another HID later, that would result in a new prompt, the same as a brand new device. If it changes HID while plugged in, that could even be a more severe message along the lines of "Hey, this keyboard just tried to become a video adapter and thumb drive, that's really suspicious and you should probably destroy it with fire". Likewise, VID/PID changing without being unplugged/replugged in, changing too quickly, or even just after too many new VID/PIDs in a short time period should result in a temporary lockdown -- in the same way fail2ban blocks repeated login attempts from a given IP.
- geofft 8y ago
  What prevents a malicious device from pretending to be a common model of keyboard (say the most common Apple or Dell one)?