Slashdot Mirror
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."
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).
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.
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 :
So many well known enterprice Antivurs/Firewall companys create drivers that lead to security flaws and it is not limited to Windows....
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
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
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
XML - A clever joke would be here if
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.
The Crimson Dragon
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.
You can't handle the truth.
Well, ATI's drivers have always been nasty. Now I can call them "viral"? :)
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.
If you mod me down, I shall become more powerful than you could possibly imagine.
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).
Any program relying on (nontrivial) preemptive multithreading will be buggy.