Device Drivers Filled with Flaws, Pose Risk

Gary W. Longsine writes "Security Focus describes device drivers as an untapped source of buffer overflows, posing substantial risk not typically considered as part of a standard risk assessment. The security risks of device drivers on both Windows and Linux, including network (remotely exploitable) and hardware drivers (typically only locally exploitable) are discussed in the article. I've noticed that software you wouldn't expect sometimes installs a device driver component. I can understand this as a component of an antivirus or host based firewall, but it seems to be an oddly common design pattern on Windows, which clearly poses substantial risk."

Comments

Design pattern

[davidstrauss]

oddly common design pattern on Windows

Could someone give me examples of this? Most software I use doesn't do this. It seems more of a design pattern for DRM stuff (like DVD audio).

One hardware driver one from way back.

[Anonymous Coward]

Sending a modem user a ping with +++ATH0 embedded. As soon as it was returned, those modems with defective modem drivers that didn't filter anything would hang up. Quick simple DoS.

Surprisingly it still works on some systems more than 18 years after I first tried it.

Multimedia Keyboards

[Lucractius]

seems these are almost everywhere these days. and with all the odd keys a lot of them Do need their own custom drivers for the extra keys and knobs and dials etc.

whatever happend to the good old days when an IBM model M was all you needed :)

Windows design flaws

[typical]

The real cause of most reboots are attempts to replace active user-mode executables (EXE or DLL). Executable files cannot be replaced while they're running. This makes it practically impossible to update system DLL's without a reboot, since they're going to running in some process all the time.

Yup. This is a major design flaw in the Windows kernel that dates way back. It's a significant part of the reason that you don't have to reboot Linux for anything other than a new kernel, but Windows frequently needs to be rebooted for user-level application installations.

It's on my list of "stupid design decisions made in Windows" (where "Windows" == NT family, not 9x family).

Other goodies are:

* "pageable kernel memory pools" (sounds like a good idea, but significantly increases complexity of writing kernel code and ease of introducing lockup bugs) over Linux's approach of just unloading modules

* Microsoft's decision to not support "real" links, just shortcuts, in their user-mode software.

* Allowing application software to "block" a shutdown.

* Not allowing Windows to run without VM.

* Not designing Windows to be able to run off of read-only media.

* Godawful shell (not fundamental to the OS, and hopefully will fixed in Longhorn) and virtual terminal, to the point where most Windows users hate the terminal.

* Bad VM algorithms. I don't know what they use, but try running low on memory on a Windows box and the system becomes bloody unusable.

(From a developer standpoint)

* Poor sockets implementation (which is still the only reasonably portable networking API under Windows -- even IOCP lacks a IOCP-able connect() up until WinXP) with no way to kick select() awake, no local-domain sockets and lots of other flaws and irritations that have to be worked around by the Windows sockets programmer.

* Never precisely specifying API behavior -- MSDN is more of a tutorial or basic user guide to the API than a true specification. Look at a Linux man page and you generally have pretty strong guarantees on the behavior of the function provided, and that isn't even the specification (those which the function conforms to are listed and you can read a hard specification of guaranteed behavior).