Well, it's in the nature of an OS, that, if you plug in a keyboard, you can type.. 

The udev maintainer and I think, that this is not a bug and not a security bug. 

That's just standard Linux behavior since forever. Udev is not in charge of anything here, it's just the kernel doing automatic driver binding. I doubt this will be changed anytime soon.

A potential fix would require a substantial overhaul over the whole architecture (Kernel and Desktop).

Hi Harald,

  thanks for your reply.

(In reply to comment #1)
> Well, it's in the nature of an OS, that, if you plug in a keyboard, you can
> type.. 

  The problem here isn't that if you plug in a keyboard, you can type (
that's expected behavior). The problem is, there is no visible warning
second / another keyboard device has been plugged in (except /dev/usb
changes | some /var/log/messages message). 

> 
> The udev maintainer and I think, that this is not a bug and not a security bug. 

  Not a bug in the sense, udev / libusb should stop responding to user
actions / second keyboard keycodes. But security issue due the fact it
is possible the added device not to be noticed / recognized in other way,
just by inspecting /dev/usb | /var/log/messages output. Since this may
too late already, we would suggest some warning dialog to be displayed
once new usb device is attached to the system (though not sure how
complex it would be to implement this).

> 
> That's just standard Linux behavior since forever. Udev is not in charge of
> anything here, it's just the kernel doing automatic driver binding. I doubt
> this will be changed anytime soon.

  See above.

> 
> A potential fix would require a substantial overhaul over the whole
> architecture (Kernel and Desktop).

  Even if it would be only displaying of some warning window?

Thanks && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team

(In reply to comment #2)
>   Even if it would be only displaying of some warning window?

Well, then you would have to add such a GUI applet to every Desktop Environment, which display a notification.

Maybe a "wall" message could be emitted.

Anyway, it's not "udev" related... udev is just notified by the system, that the kernel just has added a new device (automatically in this case). And the device node is automatically created anyway in /dev because of devtmpfs. X would then pick it up immediatly.

I just checked how Windows handles plugging in a keyboard. It pops up a bubble stating that a keyboard has been added, but no user ineraction is needed.

I think I agree with Harald on this one. It's not really a flaw by itself. I would expect my computer to start using a keyboard if I plug it in. This is especially true if we're dealing with a headless machine where we need to plugin a keyboard and monitor to fix something.

You need a compromised phone or other device. If these devices lack proper security to prevent malware, the battle is probably already lost. If we prevent keyboards from being added, there are countless other types of USB devices that could be added. There's no way to stop this on the host computer, since the device can pretend it's any sort of USB device.

What if we have the device pretend it's a CDROM drive and autorun is enabled?

What if it pretends it's a NIC (I'm not sure how this one would work exactly, but I would bet if you could make it pretend it's on a bank's local network, the machine would route through it first).

Is it possible to get a device to sniff other things on the USB hub (it would probably depend on the level of access to the USB hardware).

The possibilities are nearly endless here. We cannot fix this on the host machine. It is up to the device creators to properly secure them.

Statement:

The Red Hat Security Response Team has rated this issue as having no security
impact. We do not plan to take any action regarding this flaw at this time. If additional information becomes available at a future date, we will revisit this issue and act accordingly.