Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Windows Operating Systems Software Security IT

ATI Driver Flaw Exposes Vista Kernel to Attackers 248

Posted by CowboyNeal from the sneaking-in dept.
Shack0ption writes "An unpatched flaw in an ATI driver was at the center of the mysterious Purple Pill proof-of-concept tool that exposed a way to maliciously tamper with the Windows Vista kernel. The utility, released by Alex Ionescu and yanked an hour later after the kernel developer realized that the ATI driver flaw was not yet patched, provided an easy way to load unsigned drivers onto Vista — effectively defeating the new anti-rootkit/anti-DRM mechanism built into Microsoft's newest operating system. Ionescu confirmed his tool was exploiting a vulnerability in an ATI driver — atidsmxx.sys, version 3.0.502.0 — to patch the kernel to turn off certain checks for signed drivers. This meant that a malicious rootkit author could essentially piggyback on ATI's legitimately signed driver to tamper with the Vista kernel."
This discussion has been archived. No new comments can be posted.

ATI Driver Flaw Exposes Vista Kernel to Attackers More

ATI Driver Flaw Exposes Vista Kernel to Attackers

Comments Filter:

  • trusted computing (Score:3, Insightful)

    by Anonymous Coward on Friday August 10, 2007 @07:39AM (#20180911)
    ok...
    so windows vista trusts ATI.
    ATI trusts themselves.
    I don't trust no one, especially closed-source drivers from ATI.

    shouldn't they simply replace their "fglrx" with "ati", in their xorg.conf?

  • So I read it right? (Score:5, Funny)

    by Wooky_linuxer ( 685371 ) on Friday August 10, 2007 @07:39AM (#20180913)
    Vista has an anti-DRM mechanism built-in? Wow, and I thought Linux stood for free sofware... way to go Redmond!

    • Re: (Score:2, Insightful)

      by CarpetShark ( 865376 )

      and I thought Linux stood for free sofware...

      Linux does NOT stand for free software. It happens to have a (now old and relatively flawed) free software license. The main direction for Linux comes from a guy who likes Tivoisation (ie, DRM), and is of the opinion that politics like Freedom issues don't matter; he just wants to create tools.

      If you want a Free Software kernel, that guarantees you'll still be able to use it at version 11.6, you'll need to look further afield.

      You could argue that kernels don't

      • Re: (Score:3, Interesting)

        by sgt scrub ( 869860 )
        udev is part of the Linux kernel project, while HAL and D-BUS are not.

        So, why doesn't Linux have a HAL? I can tell you the answer in one word - Tradition. The Linux kernel emanates from kernel.org, which essentially produces a white box OS, supporting x86/IA-32 compatible CPUs. With that Wintel architecture, things like code compatibility, BIOS, and chipsets come together to form what I call the PC/AT "virtual machine." Linux, like Windows, leverages basic knowledge about this platform, so that booting a

  • That's why microkernels are useful (Score:3, Interesting)

    by Anonymous Coward on Friday August 10, 2007 @07:40AM (#20180927)
    if each driver had its own separate space, this flaw wouldn't affect the rest of the system.

    • Re:That's why microkernels are useful (Score:4, Interesting)

      by A non-mouse Coward ( 1103675 ) on Friday August 10, 2007 @10:58AM (#20182949)
      Mod Parent Up.

      Even Microsoft Research [microsoft.com] is looking into making microkernel [wikipedia.org] operating systems with their Singularity project [microsoft.com].

      Of course, the Minix 3 Project [minix3.org] has been doing this for awhile, supposedly even having a fully POSIX compliant product at this point.

      The major design factor of Microkernels [wikipedia.org] is that it's bad practice to have a trusted path from any driver or system service in kernelspace to any other driver or system service in kernelspace. Just because you're "in" doesn't mean that anything else that's "in" should trust you.

      The largest hurdle microkernels have to overcome, however, is the problem of DMA [wikipedia.org]. As long as a malicious ATI video card (nevermind the driver) has direct access to all memory locations via DMA, it could easily just patch the driver's memory at runtime every time via hardware. That's why microkernel development is going to have to go hand-in-hand with tools like IOMMU [wikipedia.org], for controlling access to critical areas of memory.

      Of course, critics often complain about Inter-process Communication (IPC) [wikipedia.org] as being another limitation to microkernels, but at this point, it's really just an implementation hurdle as there are several ways to get processes that are in different memory spaces to communicate with high performance, especially as Moore's Law brings CPUs faster and faster.

      • Re: (Score:3, Insightful)

        by sgt scrub ( 869860 )
        The largest hurdle microkernels have to overcome, however, is the problem of DMA
        Absolutely correct and imho correct for all types of kernels. As long as hardware uses system memory to function, and the location of memory is not properly restricted, this problem will persist. Drivers openly developed could easily be developed to restrict specific device types to specific memory areas.

        • Re: (Score:3, Interesting)

          by TheLink ( 130905 )
          The hardware people are going to have to fix/modify DMA anyway, if they want fast IO, hardware etc with virtualization.

          They might as well do something more innovative and useful, after all I heard they were running out of ideas on what to do with all those transistors, and resorting to stuff like more cores and more cache.

          Should sit down with the O/S, DB etc people, and brainstorm some stuff that will make doing things the "right" way easier (or even just possible). Sure there's often no real right way, but

  • Kernel Type (Score:2, Interesting)

    by canistel ( 1103079 )
    I wonder (obviously not a kernel developer here), would a micro kernel prevent these types of problems, where malicious code which normally wouldn't have permission to do things, attack a part of the kernel (video driver) which does and so gain permissions?
    • I'd prefer a decently written & thoroughly tested Kernel API to be honest. It's not like they haven't got the cash to invest in decent developmental and quality assurance practices.

    • Re:Kernel Type (Score:5, Informative)

      by TheRaven64 ( 641858 ) on Friday August 10, 2007 @08:06AM (#20181079) Journal
      Depends. A video driver needs to be able to DMA data to and from the card. Even if it's in an isolated address space, a compromised driver can write all over physical memory by telling the card to. If you have an IOMMU then this can be alleviated somewhat. Some kernel component outside the driver could provide DMA apertures in the correct places, and if it did correct validation of the driver's requests (i.e. not let it open windows anywhere into memory except where it is owned by a process using the driver) then it would be possible for a microkernel to be safe from this kind of thing.

    • Re: (Score:3, Insightful)

      by Magada ( 741361 )
      It's an interesting dilemma for Microsoft - they can't have DRM without video drivers running in kernelspace (performance issues), but DRM is broken if they allow drivers in kernelspace. Consider this: anyone can now load the vulnerable driver, apply Ionescu's magic and WHAM! I predict pirate-patched video card drivers for windows are coming soon - the oportunity to strip the DRM out of high-def movies from the comfort of your own PC is just too nice to pass up. And doing it with a legitimate copy of Vista?

      • Re:Kernel Type (Score:5, Informative)

        by drawfour ( 791912 ) on Friday August 10, 2007 @08:12AM (#20181131)
        You may have missed the part in the article where the kernel *knows* it's running unsigned binaries, and thus turns off the DRM stuff. So there is no way to strip out the DRM, since that capability will be turned off when the system detects it's running unsigned binaries.

        From the article:

        Vista is perfectly aware that an unsigned driver has been loaded: you will even get a warning a bit after the driver is loaded. This also means that PMP will become aware that the driver is loaded, and disable high-definition media playback. This means that this tool will not help you bypass DRM in any way, because the original Vista protection mechanisms are still in place. Note that on Vista 32-bit, this behavior already exists by default in the OS, so it is not a "bug" of Purple Pill.
        • That's exactly the problem: If the program runs "as" the driver, which is signed and thus trusted, the kernel does not notice that it's unsigned code. For the kernel, this is signed code. Worse (or better, depending on your POV), you run with a fairly high level of trust (being the graphics driver), thus you have a rather good chance to pop the DRM altogether.

  • Rules of the Road (Score:4, Interesting)

    by mfh ( 56 ) on Friday August 10, 2007 @07:46AM (#20180965) Homepage Journal
    When hardware drivers are responsible for system integrity, all hope of safety is permanently lost. Introducing the new battleground for virus writers... fake patches:

    YOUR VIDEO CARD NEEDS NEW DRIVERS: CLICK NEXT!!!!!
    • AFAIK, this doesn't happen. I'm under the impression each release of a driver for Vista has to be tested and signed off by MS. However it does pose the possibility of an insider creating a sekret backdoor. Once you've created one backdoor, it'd probably be a good insurance policy to create an extra one so that when the first one is discovered, you maintain access.
      • btw is there an official "test" version of vista 64 bit intended for driver developers to use that doesn't have the protections?
        • For the first part of your question, you can install debug versions of Windows. These are known as checked builds [microsoft.com]. They don't have any compiler optimization and add a lot of internal checks to help identify issues when writing drivers. In particular they do extra parameter validation. The retail builds (known as free builds) basically trust kernel-mode code to be written properly, so each function doesn't check all of its parameters for validity.

          I assume it's easy to boot checked builds into a mode that acc

          • Re: (Score:2)

            by tlhIngan ( 30335 )

            I assume it's easy to boot checked builds into a mode that accepts unsigned drivers, since that is what the build is designed to test.

            You can also just use the OEM Test Certificate to test-sign your driver, then use it on a regular Vista "free" build. The only caveat is that a driver using the OEM Test Certificate will cause the system to put "OEM Test" or some such text in the background. This is so driver writers can test their driver outside the checked environment - there are a number of things that dif

    • This is why hardware owners need to open the specs to their equipment so that the kernel writers can be responsible for writing the code. They don't need to provide any code, we can do that. That's how it works with the Linux kernel, with the exception of binary kernel drivers from ATI/Nvidia and a few other oddballs. It's actually been wildly successful for Linux and is (I think) the primary reason why Linux is so much more stable than Windows. Most of the crashes in Windows these days are from poorly writ

  • Bug or feature? (Score:2, Informative)

    by martinag ( 985168 )
    FTFA, quoting a Symantec senior manager: "Basically, that ATI driver has functionality that allows you to read and write kernel memory. It's either a bug or a feature of the driver." I guess it's a feature to the bad guys. To everyone else, it's a bug.

    • Re: (Score:3, Insightful)

      by mugenjou ( 912908 )

      I guess it's a feature to the bad guys. To everyone else, it's a bug.
      I guess it's a bug to Microsoft and the content industries. To everyone else, it's a feature.

    • Re: (Score:3, Insightful)

      by Opportunist ( 166417 )
      If you consider someone a bad guy who wants his legally purchased machine to do what he wants, then yes.

  • Ah, you kids have it easy... (Score:5, Insightful)

    by Glowing Fish ( 155236 ) on Friday August 10, 2007 @07:55AM (#20181021) Homepage
    The fact that people are actually going to the lengths of breaking into Windows by using a legitimate driver with kernel access to load in rootkits...the fact that it even requires explaining, means that Windows has reached some type of real security. I mean, with Windows 98, you would just hit enter on the login dialog box, and there you were!

    • I mean, with Windows 98, you would just hit enter on the login dialog box, and there you were!

      You had me when you clicked OK.

  • ATI will patch this (Score:5, Insightful)

    by Dekortage ( 697532 ) on Friday August 10, 2007 @07:59AM (#20181041) Homepage

    Seems like the real concern is not that ATI's code opens a security hole. You know ATI will patch it. A more important question is, how many other securely-signed drivers, etc., have similar holes? How many drivers are there in a typical Windows Vista system, anyway?

    At least Microsoft can say (with some truth) that it's not THEIR software which introduces the problem! (it actually is, of course, but not directly)

    • You know ATI will patch it.

      And how will ATI ensure that all people using the flawed drivers upgrade to the newest ones? How will the average Vista/ATI user even know that they are at risk of this flaw? Unless all those flawed systems are patched this will remain a fairly big hole to be exploited by the unscrupulous.

      • That's true. I would hope that Microsoft could roll this into its "critical updates" -- not that ALL users would get it, but it should cover a big spread.
    • "Seems like the real concern is not that ATI's code opens a security hole. You know ATI will patch it."

      That's a really naive attitude. I think Bruce Schneier put it best [schneier.com]: "Once you stop thinking about security backward, you immediately understand why the current software security paradigm of patching doesn't make us any more secure. If vulnerabilities are so common, finding a few doesn't materially reduce the quantity remaining. A system with 100 patched vulnerabilities isn't more secure than a system with

      • To quote from the Schneier column you mention: "A patched buffer overflow doesn't mean that there's one less way attackers can get into your system; it means that your design process was so lousy that it permitted buffer overflows, and there are probably thousands more lurking in your code."

        Well, Bruce, it means BOTH things: it's one less way attackers can get into the system AND the design process was lousy.

        You suggested that my attitude was that patches will fix everything. Not hardly. Read the contex

      • We know ATI does software as well as Microsoft does hardware (how many Xbox 360s are dead?);

        I assume your question is rhetorical. So an abnormal amount of Xbox 360s have problems. Microsoft, to resolve this issue, extended the warranty for every Xbox 360 to three years for free. That's a lot of commitment to their customers, above and beyond what the vast majority of the industry does when hardware defects arise. (You mention Apple; they're a good exception also. Their replacement program for faulty iBooks
    • ATI will patch it?!? ATI has, in my opinion (and I am not alone,) the worst track record among companies who write their own drivers. The hardware is not bad by any means; grab an old Rage or Radeon before the X100 series, and you can play many modern games using the open-source drivers. Works excellently. Unfortunately, they write some of the shittiest code in existence, and their driver has needed constant fixes for years now. On Linux, ATI drivers are behind both nVidia and Intel, both of whom have made
  • A kernel-level driver can own a system? No shit!

    (BTW, that's one of the reasons drivers need to be signed to run on Windows Vista x64.)
    • How long before a signing tool comes out?

      This whole business of "signing" is ridiculous. It's no safer than the current model. Perhaps even less safe, as it gives both the OS programmers and the end-users a false sense of security. "You can trust a signed driver."

      No, you can't.

      The only way I can see to make a truly safe system is to run each driver in its own VM, and create a virtual network between the drivers and the core OS. Each user-end program would also run in its own VM, and IPC would occur via the

      • Re: (Score:2)

        by trifish ( 826353 )
        The point is that an author of a malicious kernel-level Trojan horse wants to stay anonymous, but can't. The certificate authorities (Verisign etc) need to verify your identity first before they issue a code signing certificate for you.

        That's how it's much much harder for moronic script kiddies to release kernel-level Trojan horses for Vista x64. Because we (or at least the police) would be able to find out their names and addresses.
        • Exceeeept... apparently you can piggyback on signed drivers to accomplish anything you want to do. We can't just wish ATI to have non-crappy code.

          At best we can hope that MS learns a few more things to add to their toolbox for refusing to sign off on kernel level drivers.

          • Re: (Score:2)

            by trifish ( 826353 )
            Red herring comment. If there's a security flaw in a driver, the vendor fixes it and you download it. It doesn't mean the system is flawed. Linux has security vulnerabilities too. It doesn't mean the system is inherently insecure forever.

            • Re: (Score:3, Interesting)

              by GTMoogle ( 968547 )
              Red herring? Is the article not a specific example of a program being able to anonymously run kernel level code, bypassing the signing mechanism? I wasn't saying it's intrinsically broken, just that what you said (anonymous code can't run) is evidently not the case.

              That it exploits a flaw in 3rd party software does not change the fact that the system is currently breakable. Signing simply makes it harder, which is certainly a good thing. It does not confer complete trust, which is what absolute statemen
      • Comment removed based on user account deletion

    • Re: (Score:2)

      by dc29A ( 636871 ) *

      A kernel-level driver can own a system? No shit!

      (BTW, that's one of the reasons drivers need to be signed to run on Windows Vista x64.)
      If by that you mean DRM, then yes. The reason drivers need to be signed is to prevent "theft", to prevent the DRM from breaking.

  • It will not work. Ever. (Score:5, Insightful)

    by Opportunist ( 166417 ) on Friday August 10, 2007 @08:29AM (#20181247)
    Actually I'm amazed it took almost a year. I would've betted my annual income that something like this would surface before May.

    Let's take a look at the inner workings of the system. Yes, MS has full access to the source code, so their drivers will probably not leak. They also have no "real" competition on the OS market (yes, there's Linux, there's MacOS, but what company would switch?). They can take their time to proof and perfect their drivers until you can be certain that they don't leak.

    Do third party vendors have the source? No. Do they have tight schedules and competition breathing down their neck? You bet. Will they prefer performance or security? Well, what of those two is tested on pages like THG?

    Worse yet, what if such a driver actually allows a user to "crack open" his system and use it as he pleases? Could you see people buy a cheap ATI card just for the purpose of disabling the DRM? I mean, there have been really, really crappy games for some consoles that sold surprisingly well, because they contained a bug that allowed disabling certain security measures. Save-game exploits were quite popular for a while.

    Could you see that this "security" bug could actually be a selling argument FOR the hardware rather than against it?

    • Re: (Score:2)

      by Tony ( 765 )
      (yes, there's Linux, there's MacOS, but what company would switch?)

      Ernie Ball [com.com]
      Wotif.com [zdnet.com.au]
      Burlington Coat Factory [computerworld.com]
      Peugeot [europa.eu]

      Just to name a few.

      And of course IBM and Novell, but they don't count, as they are strong GNU/Linux players.

      Of course, Siemens was a bit off [newsforge.com] in their prediction of 20% market share by 2008. But I'd say there's the chance we might make 20% some day.

  • I see... (Score:3, Funny)

    by lixee ( 863589 ) on Friday August 10, 2007 @08:32AM (#20181267)
    So the reason ATI is not giving us Linux users free drivers, is because they care about the security of our systems. Talk about irony!
  • The fglrx module expects the registers related to Thread Local Storage to be in a certain state. If you mess around with it, you can cause a kernel crash. Try running wincecfg from <wine-0.9.31 under valgrind (wine>=0.9.31 includes a check for fglrx in TLS mode and aborts), it will crash the kernel with 100% repeatability. You can find details in ATI and wine bugzillas.

    I always wondered if this could be turned into a more dangerous security exploit. And now I wonder how much code is shared between fgl
    • I'm sure anyone who's had much experience with the fglrx driver would be surprised if that piece of crap only contains one vulnerability ;-)

  • And this is why (Score:3)

    by Ravenscall ( 12240 ) on Friday August 10, 2007 @08:52AM (#20181439)
    And this is why I have used nVidia hardware since I upgraded from my Voodoo 3 3000. While ATI and nVidia may go back and forth in hardware performance, nVidia has much better driver support on Linux or Windows.

    *Still rather upset That there is no linux acceleration driver for the ATI Rage Mobility in the original iBook, I would much rather run Linux on it than OS X or OS 9.

  • My understanding was that video runs in ring 3 (Score:4, Interesting)

    by NullProg ( 70833 ) on Friday August 10, 2007 @09:25AM (#20181751) Homepage Journal
    Oops, I guess not....

    Because WPF is largely written in managed code on the common language runtime, it never ran in kernel mode. There are elements of WPF (called the MIL) that are written in unmanaged code, but that code also largely runs (and always has run) in user mode. Insofar as WPF needs to touch kernel mode stuff (e.g., drivers), it interacts with them through the existing DirectX APIs. The user mode and kernel mode aspects of the WPF architecture haven't changed.
    http://arstechnica.com/news.ars/post/20051216-5788 .html [arstechnica.com]

    So what did Microsoft gain with the Vista GDI changes?

    Enjoy,

    • Re: (Score:3, Informative)

      by Foolhardy ( 664051 )
      In NT 3.x, the Win32 video driver model was created from scratch. A video driver consisted of two parts: a video miniport driver that does the actual talking to hardware, resource allocation, etc., running in kernel mode and a display driver that handles all the drawing and display functions, running in user mode with the window server (winsrv.dll) hosted in csrss.exe. In NT4, Microsoft moved the window manager into kernel mode (win32k.sys), which took the display driver with it.

      Vista supports two displa
  • I only knew about the red pill and the blue pill. Hmmmmmmmmmm........

    Morpheus: This is your last chance, Neo. After this, there is no turning back.
    You take the blue pill, the story ends, you awake in your bed and believe whatever you want to believe. You take the red pill, you stay in Wonderland, and I show you how deep the rabbit-hole goes.Remember: all I'm offering is the truth, nothing more.
    Neo: And the purple pill?
    Morpheus: Oh, the purple pill gets you high. I can't guarantee what happens later.
    Neo: I'll take the purple pill. (*gulp*)
    (After a short pause...)
    Whoa, dude, I can see what's behind the mirror! Whoa... everything's like computer code! I understand what the Matrix is now!!
    (Back in the nebuchadnezzar...)
    WE'RE LOSING HIM!
    Neo: I can fly dude!!! Excellent!!!
    Flatline: beeeeeeeeeeeeeeeeeeeeeeeep....

    (Some time later...)
    Trinity: Seriously, Morpheus. This is the 20th time we lose a potential "One" because of the purple pill!
    Morpheus: He wasn't "The One". "The One" would have survived.
    Trinity: Idiot.


    Now, seriously, what's "purple pill"?

    • That's different to the purple pill one I heard:

      Morpheus: You take the purple pill, you wake up in your bed and I show you how far the rabbit-hole goes.
      Regards
      elFarto
  • For the longest time I thought that all ATI drivers sucked equally on all platforms. But I guess they suck even more on Windows then they do on Linux.
  • A few months back (after over 12 years with Linux) I finally took the plunge and went Linux-only on my main home PC. I went with Ubuntu 7.04 simply for the basic completeness and fair stability. There are some of the same glaring issues that have plagued Linux since 12 years ago which is so damn frustrating I can't even begin to explain it, there are still some big unification/usability flaws, but the one thing I don't miss at all? Shit like this. A video driver opening a hole that I can't see or close that
    • Honest question, not intended as flamebait - I really don't know the answer. Has any Linux distro implemented true, system-wide copy/cut & paste? As minor as it is, it's one of the niggling little annoyances that prevented me from switching quite some time ago (last time this was the reason was, I think, when I was trying RedHat 5). Other problems have prevented me since (Inkjet drivers at one point, wireless NIC drivers at another, wireless USB dongle drivers currently), but I've reason to believe they
      • Truthfully, I hear this a lot, but it has never affected me. I do mainly stick to Gnome and Gnome-based apps, but I use Amarok, K3B, and a few other KDE apps and have never had any trouble with copy/paste. I will say that it is an issue that needs addressed, along with a number of other UI and UI unification issues. All the levels of abstraction are great at times, but in reality it does make for a mess that is too complex for the average user.

        I never understand why we have to insist on having X, a desktop

        • I never understand why we have to insist on having X, a desktop environment, AND a window manager for average desktop systems. I would absolutely kill for an all-in-one system geared for home use. No choice, no thousand and one options. I also wouldn't mind a distro to be tuned for at most 4 users at once.

          The fact that the X server, the window manager, the window decorator, the compositor, the selection manager, and the `desktop environment' (which is really a big compositum of many many parts) are separate pieces is rather irrelevant for `home use' or for mostly any other use apart from developing them. Windows does separate some of those roles too (you can change the window manager, for example)

          Most of the popular distros of the day do not really present a huge number of options. If you install Fedora,

      • I had the same questions too about cut and pasting.

        Simply enough, hilight/middle-click works on every X-Windows application. If it's a gnome app, works. If it's a kde app, it works. If it's a motif (egads), it works.

        It just works.
    • What are you talking about?

      Linux is rooted ROUTINELY. It just rarely gets reported on in /.

      There was just a giant BSD root festival reported on yesterday.

      "Shit like this" happens everywhere and ignoreing it or pretending it doesn't exist on Linux is just plain ignorant.
  • So will Microsoft lobby Verisign [pcmag.com] to revoke ATI's certificate, and add the ATI driver to Windows Defender's malware list now that this hack to circumvent the DRM on HD video is out there in the wild?

Slashdot Top Deals

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Close