last day (15 days later) » 

19:51
36
Q: Why don't OSes protect against untrusted USB keyboards?

trallgormLately I've been reading about things like BadUSB and RubberDucky which are essentially USB sticks that tell the computer they are a keyboard. Once they are plugged in they "type in" whatever commands they were told to execute. My question is, why are keyboards automatically trusted in almost eve...

For the same reason that you don't choose where you're born: OSs do not choose what hardware gets plugged in and how it is processed by the BIOS and presented to them.
How would you type in the password for the keyboard without the keyboard?!
@spacetyper You would use the new keyboard. The point was that it would not, for example, be able to "press" the shortcut for cmd and then enter commands through there, until it entered the password. I don't see any harm in just letting it type stuff into the password field.
I'm sure this is a duplicate but I can't find the original
If the bad guys get physical access to your machine long enough to plug a USB to it, you've already lost.
19:51
How would you type in a password for a keyboard using that keyboard, when that keyboard is not a keyboard? Or that keyboard only has three buttons?
@8bittree That's a really good point. Is there a way for the computer to tell what kind of device is plugged in?
It is possible in the specific case, e.g. Logitech's software will program their devices, but not Microsoft's. But, that G700s is also usable on computers without Logitech's software installed, the only limit is you can't reprogram it. But any settings already saved to the mouse, still work. So I'm not sure if it's possible or feasible for an operating system to have knowledge of every single USB device. And there's still the problem of bad devices pretending to be good devices.
USB hardware is not "processed by the BIOS" except when the BIOS has control of the system at boot. The BIOS uses SMI to make USB keyboards appear as PS/2 ones until a non-DOS, etc. operating system initializes ACPI. At that point the OS needs a driver for and has control of the USB controller, as well as full visibility of devices on it.
@Mindwin: The bad guys only need to sell you a fake keyboard. They don't need physical access to your computer.
I think a better way to phrase this is 'Do any operating systems implement a security model for USB devices similar to bluetooth pairing'?
19:51
The following heuristic is far from foolproof, but you might be able to catch a lot of cases if the computer presented a dialog when a second keyboard was plugged in. (Almost) everyone wants to use a keyboard, but not so many want to use two at once, so adding a keyboard when one is already present is perhaps a reasonable indicator that something is strange. The threshold could be made configurable, for people who know that they routinely use other keyboard-like devices: even if you routinely use a keyboard, the G700s, and an Optimus Mini, you probably don't want to use four keyboards.
Incidentally, asking the user to use the new keyboard to type in a password/key is already how Bluetooth keyboards work, at least under Mac OS X.
@TheSpooniest You can do that for example with USBGuard which was presented at this year's fosdem: fosdem.org/2016/schedule/event/usbguard . The video of the talk is already online. mirrors.dotsrc.org/fosdem/2016/h1309/usbguard.mp4 If I recall correctly, you can configure it so that the first keyboard is allowed but the second usb device wanting to use the keyboard interface gets blocked. Disclaimer: I'm not involved in the project. I only heard the talk.
@Relaxed, like 8bittree's comment - if you've got something like a conference presenter with only PgUp/PgDn, how do you pair it? I actually have one intended for a mac, but used on Linux and Windows. It appears as a mouse and a keyboard.
@8bittree ...Morse code?
19:51
It's simple really: if a second keyboard is plugged in, all you need is a confirmation coming from the first keyboard to enable it. Or indeed any device that is already enabled.
@8bittree Then you have a secondary mechanism where the user can enable the "weird" keyboard in the OS by typing their password into a prompt. Using the same keyboard to type the password would simply be a way to avoid getting locked out. The unsupported use case is now down to one where the user can only ever use the "weird" keyboard and, not even temporarily for typing a password, a regular one.
If the bad guys can sell you a fake keyboard, they can already capture your passwords, or bank account details, or anything else you choose to type.
@ChrisH I don't think I expressed an opinion about this one way or the other. But you could imagine some sort of special driver, having to somehow pair or unlock your presenter's keypad with a real keyboard or mouse or simply not support it at all. It's quite an exotic device people were able to develop precisely because keyboards are trusted by default, not really a fundamental reason why things work that way in the first place. My point was simply that the “How do you type the password with no keyboard?” argument does not hold water, in general, and I don't think your example undermines it.
@Relaxed I just thought you might know how apple got round the problem. A magic code approach would have to know what keys the device supports of course.

last day (15 days later) »