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."
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.
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....
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?).
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
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
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!
Switch back to Slashdot's D1 system.
Some ping programs let you specify the payload in the ping packet. It's usually just used to bloat the packet for MTU testing.
+++ATH0 is the modem command to hangup.
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
On Linux/UNIX, you simply construct a custom ICMP packet (similar to a ping packet) using a language like C. I imagine a driver had to be used in Windows due to some issues with doing this with WinSock.
+++ATH0 is the command you send to the modem to make it hang up.
+++ is the modem comand to break out of the data mode and go into command mode
ATHO means "hang up"
so, "+++ATH0" being sent from the computer means hang this modem up now!
to embed that into a ping, use the "ping -f data" command, with data being +++ATH0 in aschii/hex
If I have nothing to hide, don't search me
> How exaclty does one "embed" something in a ping cmd, and
> what does +++ATH0 mean?
ping -p 2b2b2b415448300d
+++ puts a modem into command mode
AT tells it to come to attention
H0 tells it to change hook status to 0 (which means hangup)
when this is sent from a machine connected to a modem that's vulnerable, it will tell the modem to execute those commands. The return ping is what does this.
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.)
One line blog. I hear that they're called Twitters now.
Not only device drivers! :-)
The Tao of math: The numbers you can count are not the real numbers.
Well, ATI's drivers have always been nasty. Now I can call them "viral"? :)
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
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
My favourite part of Starforce is that it installs a device driver without asking the user first - you run the game, it silently installs a device driver.
Nice.
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.
Sure, but I think he still has a point.
Drivers that come with the OS may still be drivers, but they can be patched through the OS vendor's normal software update process.
Third-party drivers? Who knows?
someone might try to view comments and keep getting disconnected right at this moment.
How would that happen? The command has to be fed to the modem from the local system. If they type it into a reply and post it, then I could see that happening, but not just from reading. This is why the original poster said that it should be in a ping command -- the reply causes the hangup, not the ping.
Of course, there's also the point that someone else made that the modem is only supposed to enter command mode if the +++ followed (and preceeded, I think) by one second of guard time.
Yeah but the dead giveaway with Starforce is that it requires a reboot after you install the game. We all know why Windows needs to reboot post-install: drivers.
Well, actually, Windows will reboot post install for a number of reasons, but for a game using Starforce, it makes sense.
Wrong! Installing drivers is not a major cause of reboots on Windows. The only time you absolutely need to reboot is if you update the boot disk driver. There is no different than Linux. Any properly written Windows driver can be installed or updated without a reboot -- if the driver writer didn't do their job, blame them, not the OS.
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.
The key sequence to access my Slashdot bookmark in Firefox is Alt-B-S. I don't believe this is a coincidence.
oh god no!
I tried that once. it suggested an update for my network card and pretty much fucked my system.
never again. never.
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.
The key sequence to access my Slashdot bookmark in Firefox is Alt-B-S. I don't believe this is a coincidence.
All drivers run in the same kernel mode virtual address space (usually the top 2GB) plus the current process's virtual address space. Drivers are free to call the native Zw* functions, the ones that don't do security checks or validation. Drivers can access the same Object Manager namespace as everyone else so there aren't any 'hidden' drivers.
There's nothing stopping a driver running malicious code from connecting to the \Device\Tcp device to open a socket, using ZwCreateFile to copy a malware app into the Windows directory and using ZwCreateKey to install it as a new service.
There's also nothing stopping a driver from posting a kernel APC onto a thread from a user-mode victim process so that the driver can load malicious code into the process. After that, it's as simple as changing the thread's thread environment block to return into the new code's address. The next time the thread is scheduled, the malicious code will be running. All with zero access checks.
STOP errors do in fact occur when a driver tries to access certain read-only memory sections. These are sections that were setup at boot time and should never be changed. You're right about the purpose of STOP errors (die if there's any chance of corruption) and why the video drivers are avoided.