Can Microsoft ever stop kernel tampering in Vista?

Can Microsoft ever stop kernel tampering in Vista?

Summary: I was just going through the slides from Joanna Rutkowska's Black Hat talk (127-page .ppt file) and discovered that there's another unpatched driver flaw that exposes Windows Vista to kernel tampering.

SHARE:
48

I was just going through the slides from Joanna Rutkowska's Black Hat talk (127-page .ppt file) and discovered that there's another unpatched driver flaw that exposes Windows Vista to kernel tampering.

This flaw, in NVIDIA nTune, is similar to the recent ATI Technologies driver issue that provides a foolproof way to load unsigned drivers onto Vista -- defeating one of the new security mechanisms built into Microsoft's newest operating system.

Can Microsoft ever stop kernel tampering in Vista?

Because the buggy driver is legitimately signed, Vista will always load it, setting up a scenario where an attacker can bring the driver to the target machine, install it and then exploit it.

[ SEE: ATI driver flaw exposes Vista kernel to attackers ]

Even in cases where all device drivers are perfect (we all know that world doesn't exist), Rutkowska showed how certificates can be purchased by anyone for $250 and attached to legitimate drivers rigged with what she calls "innocent" backdoors.

"Nobody can charge us for creating and signing an 'innocent' driver, which just happens to be somewhat buggy (a subtle buffer overflow somewhere," she argues. The driver can then be loaded into Vista (legitimately) and the attacker can simply exploit the bug to get access to the kernel.

"It's not our driver that behaves maliciously, but it's the exploit, which is not signed by any certificate."

The takeaway from Rutkowska's talk, which is not being disputed by Microsoft, is that it's not possible to implement effective kernel protection using device driver signing.

Alex Ionescu's Purple Pill, which piggy-backed on the ATI driver flaw, put Rutkowska's theory into practice and sent Redmond scurrying to look at its anti-rootkit/anti-DRM security mechanisms.

Last Tuesday, as part of Patch Day, Microsoft shipped a non-security update (see advisory here) to add additional checks to the Kernel Patch Protection system. This update, which was NOT related to the Purple Pill release, is meant to protect code and critical structures in the Windows kernel from modification by unknown code or data.

I exchanged e-mails with Ken 'Skywing' Johnson, a Microsoft SDK MVP known for breaking Vista's PatchGuard, and he explained the latest update as just another salvo in the never-ending cat-and-mouse game to attack -- and defend -- the Windows kernel.

"It changes t he way that PatchGuard's integrity checks are periodically run in an effort to break publicly available code that disabled PatchGuard v2. This includes the code that I published for disabling PatchGuard v2 in Uninformed vol 6," Johnson said.

It also extends PatchGuard's integrity check to include several other key areas that could possibly be used to achieve results similar to patching the kernel but without arousing PatchGuard's attention (which would allow one to simply ignore PatchGuard entirely and coexist with it while still altering the behavior of the kernel in ways that PatchGuard was designed to stop).

In other words, Johnson explained, it's the latest iteration in the play-by-play between Microsoft and anybody who wants to patch the kernel. "As far as I know, it is successful in stopping all of the current, publicly available code for disabling PatchGuard v2. However, a motivated and skilled individual would likely not find the new PatchGuard version unstoppable," he added.

"Microsoft is fighting a primarily reactive battle against people who are (or might be) shipping code that is designed to disable PatchGuard... I would consider it very likely that the new revision will be disabled just as effectively as v2 and v1 have, given time," Johnson argued.

For its part, Microsoft views Kernel Patch Protection and the device driver signing mechanism as "parts of a defense in depth approach to security. "

A spokesman explained to me that PatchGuard and practices such as using User Account Control (which limits how much code runs with administrative permissions) are parts of this approach that combine to make the operating system hacker-proof.

"Windows Vista was engineered to be the most secure version of Windows, however it is important to note that no operating system is 100% secure. Microsoft periodically reviews and adjusts mechanisms such as KPP based on evolving research and threads – security is an ever evolving process," he added.

Topics: Security, Microsoft, Windows

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

48 comments
Log in or register to join the discussion
  • Windows defender is supposed to be an antispyware program

    It seems lately it only is used by microsoft to get rid of unwanted hacks of their os. It doesn't stop vundo or smit-fraud or anything really. So much for the much heralded free antispyware that microsoft was giving out of the goodness of their heart. I knew it was too good to be true. It truly should be called Windows Kernel Defender.
    zmud
    • RE: Windows defender is supposed to be an antispyware program

      Actually, Defender is actually an API which security companies should use, which monitors what occurs in the kernel without needing to hack the kernel and add modules directly.

      Oh, and mate, you choose to run Windows - don't like it, move.
      Kaiwai
      • This is another case of microsoft protecting itself

        not really it's customers
        and Giant Antispyware was a pretty good product
        It is too bad they are letting it go to waste
        zmud
    • I wouldn't put too much stock in Defender

      Microsoft's Defender which is included with it's OneCare is not something that anyone should put too much stock in. Remember this is yet another, relatively new area which is still being developed much like Vista, it has issues, holes and for lack of better commentary, it SUCKS. Almost ANY 3rd party antivirus software would be a better choice. Why ? Simple, they have been out there far longer with far more focus on one thing, security for antivirus and spyware. Much like fine wine, it didn't get to be fine within a few years !
      intrepi@...
  • Captain Obvious

    [i]The takeaway from Rutkowska?s talk, which is not being disputed by Microsoft, is that it?s not possible to implement effective kernel protection using device driver signing.[/i]

    ... which stunning news is exactly what people were telling MS back when they first came up with the brainstorm for driver signing.

    Sort of like DirectX and the rest: MS has brainstorm, world+dog point out that it's b0rk3n by design, MS puts it into production, years of hilarity ensues, finally MS has an epiphany which reveals to them that there's a design flaw, and the whole cycle repeats.
    Yagotta B. Kidding
    • Captain Oblivious

      So your take-away is that because NVidia and ATI implemented drivers which could be exploited that it is Microsoft's fault?

      Yagotta B. Kidding is right.

      Microsoft is d*mned if they do and d*mned if they don't.

      If they don't allow developers to write software and drivers for their OS, they are being proprietary and anti-competitive (funny how Apple never gets accused of this, though they limit the hardware very specifically.)

      If MS does open allow anybody and their brother to write code/drivers/etc for their OS, they open themselves up to this kind of exploit, but that is not the developers problem, that is MSs?

      Get off of it and realize that the problem is sloppy coding, and in this case, that sloppy coding was at ATI & NVidia.
      Hamlet_z
      • Other methods of kernal protection by other OS are better...

        You are partially correct, except that other methods of kernel protection by other OS are better.

        MS didn't go the route other OS have of protecting the kernal and separating drivers from having direct access to kernal to maintain a level of backwards compatibility.

        Problem is their method of protection has a flaw and doesn't work as intended. There will always be sloppy coding, that is exactly why and what you want to protect the kernel from, not an excuse for not being able to protect the kernel.

        Access to the kernel is the Master Key to being Owned.
        jjarman
        • Revisionist History...

          Now, you and I both know that Windows would not be the gaming platform that it is, and could not have the performance needed for other real-time hardware control, if it did not use kernel-level drivers.

          What OS are you thinking of that does not support kernel-level drivers? OSX does, so does Linux. And what hardware manufacturer would choose to deliver slower performance by not providing a kernel-level driver when that's an option?
          jcg_z
          • Any standard BSD-based UNIX, and some Linux

            Set your securelevel greater than 1 and you can't install new kernel drivers after boot,
            nor can you modify immutable files, or make a variety of other changes to the system
            - including reducing the securelevel without rebooting. In addition, you can build a
            completely static kernel that uses no drivers other than the ones linked into it. This
            can actually produce a slightly faster system by allowing more aggressive kernel
            optimization and avoiding any dynamic linking overhead such as jump tables.

            Google tells me that there are securelevel ports for Linux, as well.
            Resuna
          • Many OS protect and managed access to the kernal level interfaces

            I think we mostly agree, my wording was unclear, my apologies.

            I simply meant that the managed kernel level access many OS use provides a level of separation and security that you can never acheive with full unprotected kernel level access.

            Full pants down unprotected access with just a signed name tag, is not a good idea.

            Does a video driver need access to every aspect of the kernel or merely certain functions? Lookup all the additional security measures that OS X, BSDs, and certain linux provide.

            Controlled, regulated, access to only certain key functionality, with protection is very different. That was the route everyone was encouraging MS to go, and they did try and go that route, but switched back with the longhorn abandonment. They tried to switch to the more secure model similar to the one used in other os, but abandon that effort in favor of signed name tags.

            They tried to do this in Vista and, as Sxooter_z points out NT 3.51 had full separation. It wasn't my intention to revise history or be unclear, my apologies if I did either.

            Cheers.
            jjarman
      • No, he's right, it's Microsof's fault...

        Microsoft isn't responsible for the buggy drivers but they ARE responsible for thinking this could ever work.

        It's the exact same problem they had with ActiveX in Windows 95 - the bizarre belief that all signed code would be perfect and trustworthy.

        It isn't it never will be, people have been telling them this for fifteen years or more, but they still persist with this doomed security model.

        So yes, it's Microsoft's fault.
        jinko
      • It's the design, silly

        Who's idea was it to implement kernel-level drivers? ATI? NVIDIA?

        Who's hair-brained idea was is that only loading signed drivers would prevent malicious code from modifying the kernel?

        The problem is the design, not the implementation.

        Got it?
        SpikeyMike
      • Point

        The problem here is not Microsoft (although their design allows the hole) or NVIDIA/ATI (although their code opens the hole) or the researchers (who find the hole and tell us about it so we can take precautions) or the users (who when told of the hole and patches do become available, don't apply them) BUT the problem is the malware/virus writers who exploit the hole.
        A comparison:
        Is it Fords fault that someone can pick the lock on your car, hot wire it and steal it or is it the guy stealing the cars fault?
        We don't blame Ford we blame the thief. Why do we blame MS here?
        Ford in good faith puts locks on cars to stop them from being stolen. Drivers lock their doors. Cars get stolen.
        Microsoft in good faith has put a lot more into Vista then Ford in your car. They have done a good job of it, there is more protection in Windows for your computer then in a Ford for your car. Yet everyone continues to blame MS for everything from Viruses to browsers being hi-jacked to porn sites.
        If we put one tenth the effort into stopping the bad guys from exploiting our computers as we do in blaming MS/Nvidia/Linux/Firefox ... then we would catch more of these guys.

        I think the comparison is apt and I am starting to wonder at the psychology of the issue, why do people blame the vendor when it comes to computers but the thieves when it comes to everything else. (cars good example.)
        sysop-dr
        • Bad analogy

          If cars were computers, we would all be walking
          If gm or ford was as sloppy as microsoft, they would have been sued into oblivion long ago.
          zmud
      • NT 3.51

        Once upon a time, there was an OS called NT3.51. It had a layered microkernel that put device drivers outside the inner rings of the kernel, and if a device driver acted up, it couldn't get the access level needed to scram the kernel and hijack the system.

        Microsoft shoved all the kernel drivers in the ring0 (the inner ring) in NT 4.0 cause that made it faster.

        So yes, it is Microsoft's fault.
        Sxooter_z
  • Making the perfect the enemy of the good

    You seem to be arguing that if protection isn't perfect it's ineffective. That's not a fair way to look at it.

    And perhaps there's less to the driver example than it seems. It's not easy to load a device driver. You need to be admin and you'll probably have a UAC prompt. And will an NVidia driver load on a system without the right NVidia hardware?

    Rutkowska doesn't go so far as to belittle facilities like these just because they aren't perfect. I don't see why you should.
    larry@...
    • I really would like you for a boss

      Good thing I don't work for any of the Banks, Investment Brokers or Stockmarkets or I'd have to wish you off my list for future bosses.
      Look, it's not us that are making the implications, the assertions or the software. It isn't me or the other guys who are saying it's the latest, greatest and most wonderful products from MS which you really need to have, ( for a price ). Let me ask you this, if I had a flyswatter and stood in the middle of a South Dakota cornfield and killed every bug in sight, would you hire me to protect the US of A from killer bees ? Well with this thought in mind, reconsider your post.
      intrepi@...
  • Yes, it can be fixed

    But it won't be easy.

    Eliminate the kernel / user dichotomy. Make it kernel / driver / user instead. The legacy two ring system is not good and a throwback to when NT was portable.
    rpmyers1
  • Legs Kicked Out From Beneath Vista

    The only possible reason for going to Vista was better security. Now, there is no good reason.

    Why spend all that time, money, and struggle with bad drivers, memory and video requirements that are costly; just to get where Windows XP is already. This is especially true now that Vista's security is shown to be suspect.
    chessmen
    • I still believe it is the complexity.

      Video drivers are literally operating systems in their own right. They do a heck of a lot of processing. When your ONLY goal is to create the best driver with the fastest processing, best colors, superfast DSP, then you have to overlay the DRM spec to intentionally mess with what a video card is supposed to do, it leads to more complexity, less test coverage and more holes.

      MS would have been so much better off not trying to make the security mechanisms to thwart hackers intertwined with DRM. It's too hard to stop either or, but when you try to do both at the same time in the same way with the same code.

      I hope I am wrong, but I see the DRM path just being more avenues for the hackers to play with.

      TripleII
      TripleII-21189418044173169409978279405827