Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Security Bug

Device Drivers Filled with Flaws, Pose Risk 189

Posted by CowboyNeal from the enemy-within dept.
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."
This discussion has been archived. No new comments can be posted.

Device Drivers Filled with Flaws, Pose Risk More

Device Drivers Filled with Flaws, Pose Risk

Comments Filter:

  • Design pattern (Score:4, Interesting)

    by davidstrauss ( 544062 ) <david@davidst[ ]ss.net ['rau' in gap]> on Saturday May 28, 2005 @11:02AM (#12664216)
    oddly common design pattern on Windows

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

    • Re:Design pattern (Score:5, Informative)

      by Anonymous Coward on Saturday May 28, 2005 @11:08AM (#12664242)
      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.

      • Re:Design pattern (Score:3, Informative)

        by Tim Browse ( 9263 )
        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.

        • Re:Design pattern (Score:3, Informative)

          by Afrosheen ( 42464 )
          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.

          • Re:Design pattern (Score:3, Informative)

            by Anon E. Muss ( 808473 )

            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 i

            • So tell NVIDIA and ATI to 'fix' their drivers, since they don't fit into your reboot logic. It's quite a bit different than Linux in this respect. I can change Nvidia drivers at will with no reboot in Linux, and that's impossible in Windows.

              BTW what is a boot disk driver? Is it something that you'd use if you, say, hot swapped your boot drive from IDE to SATA? Makes no sense my friend.
              • So tell NVIDIA and ATI to 'fix' their drivers, since they don't fit into your reboot logic. It's quite a bit different than Linux in this respect. I can change Nvidia drivers at will with no reboot in Linux, and that's impossible in Windows.

                Funny, I just changed my laptop's nvidia drivers two days ago, and no reboot was required. Are you sure you have your facts straight?
                • You may be right, while splitting a fine hair. Maybe I was unclear.

                  When going from the default Windows driver to the 'real' Nvidia display drivers, there is a reboot required, no ifs ands or buts. Subsequent upgrades may not require this (as I don't constantly upgrade nvidia drivers on windows machines).

                  My original point still stands, installing drivers requires a Windows reboot (under certain circumstances).

                  Jeez, this is /., where did all these Windows defenders come from anyway?
                  • I've been here all along. And I consider myself more of a truth defender than a windows defender. I'll happily bash FUD for any side.

                    I think a reboot is required when one driver doesn't "fit" the hardware in place. I'm not sure of the specifics. But in my experience, if any driver (except for a mass storage driver on which the boot volume resides) requires a reboot, you're probably using the wrong driver, or a very poorly made "driver install utility".

                    So yes, I suppose your point stands, but only real

            • 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.

              I've required post-install reboots in the following situations:
              - Video device driver installations. (Win95-A also required restarting when you changed bit-depth.)
              - Microsoft Age of Mythology, when it installed MS-XML on a system that did not include it previously. (Which seems to explain why it needs Admin privilages to install. System was XP.)
              - Clon

            • Windows design flaws (Score:3, Interesting)

              by typical ( 886006 )
              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 ne
              • "virtual terminal, to the point where most Windows users hate the terminal"

                Windows Server 2003 significantly improves the terminal. It's not quite BASH, but it's actually pretty usable.

                "Microsoft's decision to not support "real" links, just shortcuts, in their user-mode software."

                This is a UI choice. Symlinks can behave poorly if they are abused. If you want them in Windows, there's a command-line tool to do it (in the XP resource kit) or you can get a program like Junction Link Magic. It's part of the k
      • Hence my suggestion that it's often DRM.

    • there are many examples ... (Score:5, Informative)

      by tronicum ( 617382 ) * on Saturday May 28, 2005 @11:12AM (#12664258)
      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 [securiteam.com] 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....

      • very useful information in all links provided
      • Note that this applies to scanning streams for virus content, not the basic port blocking. Actively scanning all network traffic for last week's list of known viruses seems wasteful and a violation of KISS.
      • So many well known enterprice Antivurs/Firewall companys create drivers that lead to security flaws and it is not limited to Windows....

        Thanks for the information. Do you have any examples of non-Windows operating systems that have this category of problem in firewall software? (Antivirus not being an issue except for pre-OSX Macs.)

    • Re:Design pattern (Score:5, Informative)

      by nmb3000 ( 741169 ) on Saturday May 28, 2005 @11:12AM (#12664259) Journal
      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?).
      • So basically device drivers are used to get around the intentional design limitations? Abstracting user software from kernel software is a good idea, and getting around it doesn't sound like a good idea. Sure, you get performance but you lose speed.
        • Oops, I mean, sure you get performance but you stand to lose system stability, and apparently, security.
        • this kind of behavior dates back to the PC/XT era when some clever lotus programers used to bypass DOS for a gain in performance.

          i dont blame the 3rd party programers here. i blame MS shody work that forces them to this.

          see previous examples of "disk intensive" software that installs drivers to compensate for windows lack of performance. you dont see schillys cdrecord package installing drivers in linux, BSD, Solaris, etc. to work properly. and i can still listen to music and surf the web while it burns a

    • Re:Design pattern (Score:5, Informative)

      by moonbender ( 547943 ) <<moc.liamg> <ta> <rednebnoom>> on Saturday May 28, 2005 @11:17AM (#12664280)
      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!
      • Oh noes! I am deathly afraid of a hidden device driver called "Null" on my machine! I wish I could just do like those Linux guys do and send it to /dev/null!

        Oh, wait... :)
    • When a program wants to read or overwrite a file that is open by another program, windows locks the file preventing this.

      To get round this the solutions I found on google are to write your own file system device driver. Many such drivers are available to buy.

  • One hardware driver one from way back. (Score:5, Interesting)

    by Anonymous Coward on Saturday May 28, 2005 @11:07AM (#12664236)
    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.
  • Who was saying that user-mode device drivers, as done in true micro-kernels like QNX, was an inefficient design, again ?

  • Video games are the worst offenders (Score:5, Informative)

    by Myria ( 562655 ) on Saturday May 28, 2005 @11:13AM (#12664261)
    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 (Score:5, Interesting)

    by Lucractius ( 649116 ) <Lucractius@gmNETBSDail.com minus bsd> on Saturday May 28, 2005 @11:13AM (#12664262) Journal
    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 (Score:4, Funny)

      by AndroidCat ( 229562 ) on Saturday May 28, 2005 @12:01PM (#12664450) Homepage
      <clack><clack>Old days?<clack><clack>
    • Isnt that all in the basic HID usb drivers?
      I for my part never installed ANY drivers for keyboard or mouse, but the "page forward/back" buttons of the mouse worked at once.
      The same with my new usb keyboard... plugged in... "new HID-usb device found", after that the volume control buttons/program shortcut buttons worked at once.

      • Isnt that all in the basic HID usb drivers?

        No - there was a class of multimedia keyboards released in the Windows 95 era, which generally required a customized driver.

        One example:
        - The keyboard that was with a NEC computer purchased in ~1997 had kays that allowed launching special tasks. At the time, a special driver was required as well.
        - Some functions of the driver adjusted sound volume, and provided visual feedback on the screen. This OSD was not compatable with DirectX/OpenGL applications and

    • Re:Multimedia Keyboards (Score:3, Interesting)

      by rokzy ( 687636 )
      the worst is logitech mouse (MX900). it wants you to install shockingly ugly control software which not only wastes resources but reduces functionality.

      the box says it supports IE only (a mouse suporting a browser!? wtf!?) which refers to the forward and back butons. but if you don't install the crappy software, the buttons work fine in firefox.

      I suspect the main purpose of the software is just to try to force a taskbar icon on users to act as a form of self-advertising. it certainly isn't to make the mou

  • duh. (Score:5, Informative)

    by Crimson Dragon ( 809806 ) * on Saturday May 28, 2005 @11:17AM (#12664283) Homepage
    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.
    • You'd think that by now, programmers would have automated tools to check for buffer overflows...

      I'm not a programmer, but from what I've read on /. lazy programming is the main explanation for missing/improper bounds checking.

      Is it really that hard? Does it take that much more effort?

  • not that easy (Score:5, Insightful)

    by roman_mir ( 125474 ) on Saturday May 28, 2005 @11:20AM (#12664298) Homepage Journal
    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.

    • I agree, exploitation is tricky and I don't really expect major problems here. However, security concerns often parallel issues with stability/reliability.

      Seeing as how drivers are often closed source - even some on Linux - we rely upon IP holders and their developers for both design and maintainance. Rarely do you get good service in both areas. Especially when drivers are "free" (i.e. you pay for the product and get a driver with it), maintainance is not popular among businesses unless it is a major p
    • Good point. However, it doesn't need to be easy, it just needs to be easy enough for one sharp cracker to figure it out.

      Today there are literally thousands of variants different worms exploiting dozens of different buffer overflows. Most of them are derivative, relying on published source code produced by one person, and sometimes on a toolkit. If there are dozens or hundreds of buffer overflows in commonly used device drivers, they will get discovered and some of them will be exploited. Some of them mi

    • Re:not that easy (Score:5, Informative)

      by TwistedSpring ( 594284 ) on Saturday May 28, 2005 @12:07PM (#12664477) Homepage
      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.
      • I think that any case where a network driver will contain a flaw exploitable by stuff sent over the network will be quite rare.

        Are [secunia.com] you [ciac.org] sure? [techtarget.com]
        • Those are not drivers. Those are flaws in device firmware, which is a different matter entirely.
          • Interesting way of looking at it since ISS BlackIce Personal Firewall and BlackIce Server Protection, both mentioned as vulnerable in each of the links I provided, are host based firewalls and as such have no firmware but drivers that hook into the underlying OS.
            • Oops. I got the impression from the reports that they were independent devices. Sorry. Clearly a hardware solution would've been better than buying one of those products :)

      • Re:not that easy (Score:3, Informative)

        by Foolhardy ( 664051 )
        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 th

  • ATI (Score:4, Informative)

    by sabernet ( 751826 ) on Saturday May 28, 2005 @11:27AM (#12664331) Homepage
    Well, ATI's drivers have always been nasty. Now I can call them "viral"? :)
    • I've seen many complaints about ATI drivers.

      The odd thing is, I have owned more ATI cards than any other brand ('cept maybe Matrox in my older systems), and I've never really had a notable stability or performance problem with ATI drivers, except with the installer for a Fire GL X1. For some reason, you have to have the card in the computer to get to the point where the ATI installer will let you get to the point where you can uninstall the drivers.

  • 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 mor

    • Re:Why is this a bigger risk on windows? (Score:4, Insightful)

      by Gary W. Longsine ( 124661 ) on Saturday May 28, 2005 @12:19PM (#12664529) Homepage Journal
      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.

  • How to make money from this (Score:1, Interesting)

    by Anonymous Coward
    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 spreadshe
    • Oh please. That chain of events is so silly as to be worse than the current SCO antics.

      Certain spreadsheets...
      Which ones? Identified how? You have specific information of exactly how they compute cost/earnings?

      Buy a small manufacturer of CDROMS
      Uh, yeah. OK.

      Sell the resultant equipment...
      How many corps buy individual CDROM drives? How do you convince them to buy yours?
      Keep other companies from buying your borked CDROM drives?

      Wait four years...
      By which time they will most likely have changed Excel

      • Agreed. However, what about writing an anti-spam, anti-virus, or anti-spyware app and giving it away to businesses on some sort of introductory "promotional" offer?

        Even better, with these programs there is a valid reason to connect to the internet (i.e. to get definitions and app. updates). It would probably cost less than 10M too (mind you, creating a CDROM brand from scratch doesn't cost nearly 10M, outside of a handful of top-end firms, it's all private label + customizations now).
    • "4. Insert the virus into their device drivers."

      They must be running very outdated OSes...

      Between 5 CD-ROMs, 3 CD-RWs, 1 DVD/CD-RW, and 1 DVD+-RW I have never needed a driver on any OS other than DOS. Even for DOS, it still just used a generic driver which shipped with the OS, not a manufacturer-provided piece of software.
  • 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 :-)

  • "Built For Windows" (Score:3, Insightful)

    by CdBee ( 742846 ) on Saturday May 28, 2005 @12:08PM (#12664482)
    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...

  • Device Drivers Filled with Flaws, Pose Risk

    Another Slashdot typo: they obviously misspelt "SUV" as "Device".

  • Open Documentation == Safe & Reliable Drivers (Score:3, Interesting)

    by shking ( 125052 ) <babulicm&cuug,ab,ca> on Saturday May 28, 2005 @01:19PM (#12664895) Homepage
    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 [slashdot.org].
  • 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 [maushammer.com] 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 [verizon.net] need to rely on libusb, a generic os-level driver that passes user-level co

  • Why do we even need device drivers at all? (Score:3, Interesting)

    by Skapare ( 16644 ) on Saturday May 28, 2005 @09:30PM (#12667543) Homepage

    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.

Slashdot Top Deals

"If it's not loud, it doesn't work!" -- Blank Reg, from "Max Headroom"

Close