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

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.

Re:One hardware driver one from way back.

[AndroidCat]

That should only work with modems that took the cheap route. +++ is supposed to be wrapped with a guard delay that would prevent that. (There's probably some vulture lawyers still charging licence fees for Hayes' patent on that.)

Re:One hardware driver one from way back.

[Myria]

REAL modem drivers would use ATS2=255, which disables the +++ string. Then, to hang up, you drop the Terminal Ready (TR) bit of the serial port. This way, there is no string that can hang up the modem.

Melissa

Re:One hardware driver one from way back.

[Anon E. Muss]

The delay after +++ was patented by Hayes. After the "Hayes AT standard" was firmly established in the market, Hayes started suing other modem manufacturers for patent infringement. Many decided to remove the delay requirement rather than pay royalties. There are a lot of modems that will hang up if they receive "+++ATH0\r" in a continuous stream.

Re:Design pattern

[Anonymous Coward]

Games do this often for their copy-protection methods. The most common is Starforce, which installs a driver without which the program will not run.

there are many examples ...

[tronicum]

Most direct disc access (antivirus) or "personal firewall" products install theirself as driver between the physical and logical layer.

This leads to many problems like stuff found recently in almost all Computer Associates eTrust Antivirus products. Because Zonealarm licenced the same software, they were affected, too.

This is just one example of many :

• McAfee
• Trend Micro
• F-Secure
• Symantec

So many well known enterprice Antivurs/Firewall companys create drivers that lead to security flaws and it is not limited to Windows....

Re:Design pattern

[nmb3000]

Could someone give me examples of this?

I was thinking the same thing. Obviously some stuff will have a driver it installs because it is required for whatever it's doing. Examples of valid ones roll off easy enough: Daemon Tools (ISO emulation), UltraMon (multi-monitor manager), hardware-heavy optical disk apps like Alcohol 120% and Blindwrite, OpenVPN.

I think often times the reasons behind device driver usage are linked very closely to efficiency and ease of implementation. If you need close hardware access and want to be fast and efficient doing it then a device driver is probably best. Even if it were possible doing it with some sort of hook and DLL system, it's going to be a lot slower and more of a kludge.

I figure that while device drivers are another part of software that needs to be analyzed for security flaws, they really aren't that special. One of the simplest security flaws, a buffer overflow, can still be found in who knows how many programs? The fact that a driver runs near the kernel is something to watch for, but methods like DLL injection have enabled people to get kernel-privileged access before on Windows (remember getAdmin for Win2000?).

Video games are the worst offenders

[Myria]

Video games' copy protection systems install device drivers like crazy to try to prevent CD-ROM emulators and such. Others install drivers to prevent cheating. When they do this, they often mess up the system involved and leave the system vulnerable to attack.

For example, a few months ago, the nProtect anti-cheat system, which installs device drivers, had a buffer overflow in it that allowed local privilege escalation.

Melissa

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 :)

Re:Multimedia Keyboards

[AndroidCat]

Old days?

Re:Design pattern

[moonbender]

Look for yourself, if you are on Windows anyway. Open the device manager, check "show hidden devices" in the view menu and look at the new devices that appear. Especially the ones in the "Non-Plug and Play Drivers" category. Some examples from my system include "Creative AC3 software decoder" (along with half a dozen more drivers the Audigy installs), "StyleXP helper" (Window skinning), "mnmdd" (no clue). And this is a fairly clean system, apart from Style XP maybe. Most of these would make sense as services, but device drivers? Not that there is a shortage of services on a typical Win XP system!

duh.

[Crimson Dragon]

To cite poor design as a source of security vulnerability is to state the obvious. We spend so many man hours fixing problems that didn't have to exist in the first place, that we cannot address the problems that came inevitably over the course of implementation of software packages and protocols.

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:not that easy

[TwistedSpring]

Not necessarily. In the case of network drivers, drivers installed by firewall software, and so on, the attacks can easily be performed remotely by sending stuff over the network. However, I think that any case where a network driver will contain a flaw exploitable by stuff sent over the network will be quite rare.

Drivers on Windows NT are reasonably well protected. If a driver attempts to do something it's not supposed to (like access an address outside of its assigned address space) this will be trapped by the kernel and you'll get a STOP error (BSOD). That's what the STOP errors are for, any event where a device driver has performed an action that could compromise the data in the system if the system were allowed to go on running. It's also why STOP errors drop you out to standard VGA text - to avoid using the graphics drivers anymore.

Probably the greatest security flaw you could acheive in a driver is a denial of service, although they run at the kernel level, they still don't have system-wide access. There may be some way to gain that, but I doubt it. They certainly don't have access to user mode, and to access disks and e-mail clients and so on they'd have to go up to user mode level. Due to the lockdown on their address space drivers cannot communicate with oneanother, and in order to access the disk or network they'd need to do so through another driver which they can't "see".

So the most you'd get is a BSOD, which is annoying, but you can always head into safe mode and disable the driver to fix that. If the exploit was in a disk driver or something, you could be very, very fucked though.

ATI

[sabernet]

Well, ATI's drivers have always been nasty. Now I can call them "viral"? :)

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.