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.
Code the device drivers in Rexx.
Who was saying that user-mode device drivers, as done in true micro-kernels like QNX, was an inefficient design, again ?
I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
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
I am not surpised you get this closed source drivers.
Long live open source drivers!
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
Did anyone else read the headline as "Cowboy Neal Drivers Flawed, Pose Risk?"
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.
The Chinese are not merely specialists in torturing Tibetans but are also specialists in identity theft
very useful information in all links provided
This is true, if you can get full admin access from within a networked printer you can definitely take advantage of poorly written device drivers as well. Remember software is just language, written by humans. Software will never be perfect.
Well, ATI's drivers have always been nasty. Now I can call them "viral"? :)
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.
So why is this a bigger risk for Windows? After all, what is a software driver to windows? Essentially another DLL that starts at boot, right? Well...plenty of apps install those.
My point is, why does having it be a driver make it more sinister? The system has scads of ways to autostart a DLL with full privileges.
Weaselmancer
rediculous.
1. Identify a target corporation (for example, one that makes most of its money from leasing).
2. Write a virus that inserts itself into Excel and subtly changes the results of certain spreadsheets used to calculate the cost/value of leases - by about 1%, no more.
3. Buy a small manufacturer of CDROM drives.
4. Insert the virus into their device drivers.
5. Sell the resultant equipment really cheaply to your target.
6. Wait four years until the target co. thinks it's solvent (according to your buggered spreadsheets) but actually isn't.
7a. Sell this information to a rival that wants to take it over / take it out of the market.
7b. OR Blackmail the target, threatening to reveal its status to the market / the authorities.
7c. OR Short-sell the target's stock and then make the news public.
The money you make from step 7 will be a substantial return on the investment ($10m or so?) that you made in step 3.
why so many video card producers do not want to release specs? :-)
Because with DirectX/DRI programs in userspace can access directly the hardware, and since the hardware is flawed they could easily gain root/Administrator privileges
Wondering why i am doing so strange posts? I am trying to get a "+5,Flamebait" or "-1,Insightful" rating.
Sometimes too many..
1. Linus didn't say that, Raymond did. 2. By your own analysis, all famous open-source projects should be bug-free, right? Like Firefox, right?
Stop drinking the kool-aid. Open source is not a panacea for all software development problems, and Raymond made a lot of sweeping generalities in the book you're quoting, many which make for great sound bites but are absolutely irrelevant.
Fool.
Drivers that come with the OS are still drivers.
Who told the god damn noobies about slashdot?
I'll do the stupid thing first and then you shy people follow...
I've always tried to buy hardware which is supported by default in Windows - since XP-SP2 added a bunch of new drivers this has got a lot easier.
My reasons were so that a reinstall is a simpler affair, but it appears I may have been reaping security benefits too...
I have been a user for about 10 years. This ends Feb 2014. The site's been ruined. I'm off. Dice, FU
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?
Windows Update will scan all of your third-party drivers for updates.
"We need to get over this notion, that, for Apple to win... Microsoft must lose." - Steve Jobs, 1997
SlashDot is a SPAM-whore for the IT press industry.
Something Similar is security utilities that run as root/administrator, and provide a GUI. For example, suppose your Virus Scanner or Firewall runs with higher priveledges so that it can scan all files, change it's priority, monitor network activity, etc. Now suppose it also provides a GUI with a "Disable Scanning" button. It's trivial to open the GUI and simulate UI commands.
This is most prevalent on Windows where it is common to leave an icon on the toolbar for interacting. On Linux, you usually must execute the tool separately and enter an admin password to run it.
A while back I wrote a program that would re-enable disabled GUI elements. It allowed me to get access to all sorts of stuff I wasn't supposed to. Relying on the GUI to provide security is a bad idea.
there drivers
Where drivers?
oh god no!
I tried that once. it suggested an update for my network card and pretty much fucked my system.
never again. never.
Device Drivers Filled with Flaws, Pose Risk
Another Slashdot typo: they obviously misspelt "SUV" as "Device".
Looks to me like it was Apple
In theory, the +++ should be spaced in time similar to someone pressing keys. A ping would obviously be too fast. My guess is that cheesy WinModem drivers written by underpaid programmer elves might have taken a shortcut, since timing the +++ might require something beyond their QuickBasic skills.
Perhaps the availablity of Slashdot headlines on Google's new Proto-portal.
You can live your life in a thousand ways, but it call comes down to that single day...
One more reason to help groups trying to get documentation in order write their own drivers. Manufacturers seem more concerned with slowing down their rivals than with growing their customer base (for free!). Consider OpenBSD's recent problems with Adaptec.
-- "At Microsoft, quality is job 1.1" -- PC Magazine, Nov. 1994
If done properly, a microkernel architecture is just as efficient as monolithic kernel.
The bad rep that microkernel systems have comes from lousy-performing implementations... stuff like Mach. Systems with heavyweight threads and IPC 10x slower than it should be.
Check out the L4 microkernel (or the oss rewrite of it) for an example of a microkernel that doesn't suck.
Many games 'quietly' install an unsigned driver without warning you (starforce/securom). If a single sec vuln appears in one of them and you get any damages...
I've done lots of driver development on various machines (linux, solaris, OSX, vxWorks), and my favorite for general hacking has been OSX. Besides the traditional OS-level drivers, it also allows user-level USB drivers. I use the user-level access for my projects and it provides simple no-hassle operation. The code is still limited by the user's permissions, but I don't need access to other system resources. The windows equivalents need to rely on libusb, a generic os-level driver that passes user-level commands through to the USB device. Because of window's USB driver model, though, libusb can only work for one device type and must have the VID/PID's set before installation. OSX is much simpler when you need to write a hack that modifies a device's PID - it doesn't need another driver installation to continue talking with the device.
Actually, vxworks was the easiest to write drivers for, but since it is an embedded OS with no distinction between user code and OS (they share the same namespace!), it doesn't really count.
HIV Crosses Species Barrier... into Muppets
Yep. To me it usually suggests a driver that kills my soundcard, and a buggy Nvidia driver (somehow the only driver that works together with my TV card is a really old one. The +.01 version is fucked up, and the previous ones too...)
I have a really elegant proof for Fermat's last theorem. If this sig was only a bit longer...
(Don't try this at home, script-kiddies. Each ICMP packet has a source IP field, you know.)
One line blog. I hear that they're called Twitters now.
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.
Can you do it without shutting down X, and all running X applications? Is that really so different than than a reboot? Well, it depends how you use the system. If you're familiar with Windows and use Linux mostly like a Windows workstation, running only GUI programs, and running only daemons that are inextricably linked to a GUI, then no. My system is generally running mldonkey, a host of daemons and scripts (fetching mail, sending mail, obtaining weather data, logging uptimes, a couple of servers) and it isn't even a "server" machine. I use GNU screen, so just because I happen to have a shell open in an xterm doesn't mean that I can't log out at any time. Most of the software I use (barring firefox and gkrellm) is terminal-based, so most of that sits in GNU screen. I use irssi (not x-chat), slrn (not pan). Occasionally I'll have the GIMP open, but I'm not an artist, so this is usually not the case. I use the X11 version of xemacs for the additional keys available, but xemacs doesn't need to be hooked up to a single X session (actually, it can display itself on multiple X servers at once), and shutting down X doesn't have to kill it. So, really, the only piece of software that needs lose state during a restart of X is my webbrowser. It's difficult to describe this to most Windows users, because they have a very strong and repeated set of experiences that "real software runs in a GUI". A reboot also means that I have to reauthenticate myself to my encrypted filesystems, which is the other reason that I prefer to avoid it. So I would say that, yes, a reboot of my system is very different from restarting X.
Any program relying on (nontrivial) preemptive multithreading will be buggy.
Why do we even need device drivers at all? I've worked on (used, administered) two different kinds of major operating systems (and a couple more smaller ones) that did not use device drivers at all. The answer to thise question reflects a condition that those two major OSes did not have to deal with: lack of standardized hardware.
The original IBM System 360, released in the 1960s, effectively had relatively standardized hardware. That was because IBM made all the hardware. When other manufacturers eventually made their own hardware, they were forced to make that hardware compatible. A manufacturer of a disk drive had to make it accept every hardware command that IBM's own models accepted, or it would not work. No provision existed in the operating systems for these machine to install or load a special device driver, short of modifying the source directly (which was all in assembly code for the mainframe CPU architecture).
I/O operations in the original System 360, and to a great extend in the 370 and 390 that followed, is quite uniform compared to the PC architecture. Although IBM popularized this architecture, it was actually the design of the 8088 CPU that caused things to be quite non-uniform due to it's lack of any I/O architecture (it only had a simplistic in/out CPU instruction set, which effectively functioned like fetch/store instructions in a private address space). This meant every peripheral (like a serial port) had to operate its own way. Microsoft's DOS operating system furthered the dependency on device drivers being added by making it relatively easy to do. So by combining an architecture that was very poor at I/O, absent of an I/O standard, and an OS that made discrete device drivers easy, we have this become dependent on this.
A computer architecture could still be built that includes a standardized I/O infrastructure (e.g. all devices interface the same way) and standardized I/O command set (e.g. all operations of the same class operate identically), and would not need individual device drivers. Each different class of device (e.g. a hard drive is an example of one class) would have its own I/O handling code in the OS which can be referred to as the device driver, but it would be one set of code that handles every device of that class. A command from the "hard drive handler" code in the OS to read a specific sector of storage would be exactly identical regardless of the size of the drive (if it accesses a non-existant sector, it always gets a standard error), the maker of the drive, and whether or not there is a gateway controller to interconnect legacy hardware (e.g. SCSI, IDE, SATA, etc). The same principle would be applied for all other classes of devices. All random accessible devices could then be bootable with merely the issuance of a basic "read a sector from offset N" command generated by a very simple firmware system ... for some standardized value of N for booting purposes.
now we need to go OSS in diesel cars
The older versions of the Logitech mouse software could be used for a DoS attack.
There were no parameter checks so it was possible to use simple function calls to force a Blue Screen of Death.
I've often wondered, is there a way to stop software from secretly installing drivers in Windows?
Well, I guess not running as Adminstrator probably would work, but surely there's a way to get Windows to ask "Allow Application.exe to install driver.dll ; YES / NO"?