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
