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

not that easy

[roman_mir]

let's say there is a driver and it allows a buffer overrun to execute some attacker's code. Well to get to the driver the attacker has to first go through a user application. So there is a problem when the combination user application/device driver both have a problem validating the same input. I am not saying this is impossible, but it would be more unlikely - there must be a great coincidence at work here. Besides normally user applications do not pass user input directly to the device drivers. The user applications translate input from user form to some implementation specific device driver input. So more likely than not there is a layer of input transformation between the user and device driver.

Now to go around this problem the attacker may need to get the user to execute some code on the machine and this could mean that if the code is executed - even on a Linux box for example, and the code exploits a device driver flaw, due to the monolythic kernel structure of Linux it is in principle possible to execute code that will say change user privileges to admin level. I guess this would be much more difficult with a microkernel approach like what Hurd is supposed to be, because even device drivers will run in managed memory mode.

Re:One hardware driver one from way back.

[codegen]

That's sort of the point of the ancestor post. Some drivers do not do that and are succeptible to the attack.

Re:Why is this a bigger risk on windows?

[Gary W. Longsine]

An individual instance of a given buffer overflow exploit in a device driver in and of itself is not really a bigger risk on Windows. It just seems to be a more common design pattern on Windows systems, thus creating more opportunities for exploit. (Several fine examples of questionable use of device drivers, and some associated known vulnerabilities are discussed by others here).

The referenced article at Security Focus points out that inspection of device drivers in Linux revealed similar defects in device drivers.

Device drivers are more interesting than user land software because they run in kernel space, allowing the exploit to be immediately useful to perform nasty things like install rootkits and trojans, log keystrokes, etc.