Re: Logitech Keyboard Insecurity

["KJK::Hyperion" <noog () libero it>]

At 00.15 03/05/2002, you wrote:
> >  Logitech has been contacted about 1 month ago and they have confirmed 
> > it is indeed a problem with their software, but a fix is not yet out. A 
> > 'locked' computer should indeed be locked, and not accessible via any 
> > means. While this bug is a low risk, it shows how *obvious* flaws go 
> > undetected. It totally bypasses GINA (Graphical Identification aNd 
> > Authentication), which is supposed to keep the PC secure (to the extend 
> > of requireing Ctrl-Alt-Delete to login).
> Hrrm...  Is the driver signed by Microsoft?  If it is, that seems to be 
> something that Microsoft should be checking from now on before they 
> certify keyboard drivers.

It's not the driver's fault. I highly doubt Microsoft would ever sign, no, 
wait, that Logitech would ever WRITE a driver that launched user-mode 
processes at all, as it's undocumented, unsupported, prone to errors, and 
hideosuly unsecure, not to mention very tedious to code and debug, with 
many hidden pitfalls (having rewritten Win32 CreateProcess for personal 
exercise using only NT kernel functions, I know). This doesn't apply to 
Windows 95, where launching user-mode apps from device drivers, and 
generally breaking the user-kernel barrier, is unbelievably straightforward

The hidden app that communicates with the driver (you know, the small 
bugger in the system tray) and manages the special keys is to blame, and 
it's not signed for sure - AFAIK they only sign kernel-mode executables

This is lousy design, BTW. They shouldn't allow apps to completely subvert 
the Windows input chain by allowing them to communicate directly with the 
keyboard driver, like I guess they do - the special keys should be sent as 
F13, F14, and so on, and the launcher app should receive them only by 
registering the appropriate hotkeys for the current desktop