Hacker News Reader

Comment by Someone1234 | Hacker News Reader

I hate to point out the blindly obvious, but what if you need the HID device to click on the box? So now you are stuck in a chicken/egg conundrum. You need the HID to click the box but the HID isn't installed until you click the box, great!

Unfortunately without going back to Windows 95-esk "please restart to install this keyboard" world, I cannot see how you fix this. Even blackholing some input from the HID is only at best a temp' solution (as they'd just add longer and longer sleeps before fake HID input was generated).

I guess you could redirect all HID input to a certain context (like a Virtual Desktop e.g. UAC prompt) until the user accepts it. However realistically most users would ignore this warning and just click "install" without reading it or understanding the implications.

View on HN

I have an idea: Making and breaking the USB connection itself is a form of input!

1. Supposing all the more-convenient ways have broken down (no keyboard, no mouse, etc.)

2. The OS displays a random 15-60 second countdown telling the user when to unplug the device if they trust it

3. The OS displays a second (random) countdown telling the user when to reconnect the device if they trust it.

4. If both steps succeed to a reasonable level of accuracy (some fudge-factor for humans and for slow-powering-up devices) the OS will begin trusting the HID device and installing drivers etc.

This requires no additional hardware except for a monitor, and evil devices cannot reliably brute-force it without taking a lot of time and being very obvious and obnoxious about it.

So I hand you a malicious USB stick, you plug it in, the computer asks you to unplug it and plug it back in. You do so, because you trust the USB stick (why wouldn't you, free USB stick!).

Maybe it would be better to make you type some characters on the keyboard. Similar tricks with outher human interface devices. That way the user physically can't do it with fake USB sticks.

It would require that all these devices have at least some basic functionality with only some standard drivers. I don't know how true that is right now.

What? No, the operating-system is responsible for the dialog, and it would be saying something like:

"The following USB device has requested direct control over your mouse and keyboard inputs. Do you want to grant it access?"

"Note: If you are unable to interact with your computer, please wait X seconds for emergency instructions on how to enable this device."

You can't make anything totally idiot-proof, but a lot of people will be surprised/scared when a very unusual and seldom-seen dialog pops up when they plug in a particular misbehaving memory stick.

The malicious device can just fake breaking the connection and reconnecting. No way for the PC to tell the difference.

I think that's why he mentioned using random amounts of time for disconnect and reconnect. If your malicious device guesses correctly for the simulation of "fake breaking" (let's say it only has 10% chance of doing that) and similarly for reconnecting (another 10% chance), then the malicious device only has a 1% chance of fooling the PC.

Not great, but certainly a lot better than a 100% certainty of fooling the PC.

Yep, that's what the randomness is for, and you can also add entropy by randomizing the time before the dialog starts to present he user with the "emergency connect mode instructions" which explain the disconnect/reconnect process.

Plus, 99% of the time the user is not plugging in a HID device, so the "unrecognized input device" dialog can be made ominous enough that users will realize something is very strange about that one USB stick.

Well you could do this on the second keyboard that was plugged in. In normal use my machine has an HID keyboard already attached, so attaching a second one would both be unusual, and the first one would still be around to confirm or deny the input.

Until one day you see a hilarious Reddit post that makes you spit out your coffee and your keyboard stops working. Then you plug in a new one and have no way of making it work.

Unplug the broken one first, so that when you plug the new one in the OS knows that it doesn't make sense to display a prompt because there's no keyboard to confirm it with? You'd probably want to do that anyway if you'd spilt coffee on it.

Small price to pay for usb security. Also, if your only keyboard stops working, wouldn't it accept the next keyboard by default because there isn't one connected?

> I hate to point out the blindly obvious, but what if you need the HID device to click on the box?

You just have a timed dialog with allow/block options that defaults to allow the new HID after the timeout.

What stops evil devices from simply waiting for a period of time and springing the dialog at a later time or when the user is likely AFK? (Can it detect idleness by looking at voltages?)

When a HID device is plugged in, the OS presents the user with a random number and requests that it be typed (if you only have a mouse, an on screen keyboard can be used). The newly plugged in HID device would not be fully active until the OS receives the right number. Until that time only this authorization system would receive its input (so there is no chicken and egg problem).

The OS would allow you to interact only with the confirmation dialog at first and to prevent the USB device emulating a simple click on a confirmation button it should be asking you to type in a displayed random number. So basically a CAPTCHA for USB HID devices.

A way to mark certain root ports as trusted could potentially work. This would allow you to have keyboards and mice physically plugged in to a trusted USB port while all other devices are plugged into untrusted ports.

Reply on news.ycombinator.com