ATI Driver Flaw Exposes Vista Kernel to Attackers

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

Bug or feature?

[martinag]

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:Kernel Type

[TheRaven64]

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:Kernel Type

[drawfour]

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.

Re:Let's blame Microsoft

[drawfour]

You do realize that the kernel does not do any signing, that's Verisign's job, right? The kernel only verifies that the signature is valid (and trusted). All this hack is doing is causing the kernel to turn off the part where it refuses to load an unsigned driver.

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.

Re:Let's blame Microsoft

[dkf]

You do realize that the kernel does not do any signing, that's Verisign's job, right?

Even that's wildly inaccurate, and just demonstrates that you're confused as to how digital signature systems (and other things based on a PKI too) work.

Verisign just signs the driver author's certificate, and even then just to say "these guys are who they say they are, and they're doing code signing with the key matching this certificate". They most certainly say nothing at all about the correctness of the drivers; that's up to the driver author (and maybe Microsoft too).

Re:Let's blame Microsoft

[KiloByte]

Actually, Windows will accept only stuff signed by Microsoft itself, and they take a hefty chunk of change for the privilege. You cannot also choose to have a driver which Microsoft doesn't like signed -- so that state-of-the-art professional sound processing tools are a no-no if they somehow can be used to record "premium content". Or if, say, the driver's authors somehow competes with MS.

VeriSign can sign only SSL certs and certain less-well-known types of keys for you.

Re:Let's blame Microsoft

[LurkerXXX]

This is exactly why the OpenBSD folks have been fighting against binary blobs and demanding open source drivers for hardware. Too many other open source OS's will gladly take a closed binary blob so that they can run hardware. And that leads to possible exploits down the road.

Re:Let's blame Microsoft

[Anonymous Coward]

Please cite a source for this FUD.

Or read this: http://www.microsoft.com/whdc/winlogo/drvsign/kmsi gning.mspx [microsoft.com]

You *can* buy a software publishing certificate from VeriSign and you *can* use it to sign a driver which you *can* load in Vista.

Partly correct (slightly OT)

[Lonewolf666]

Windows Vista is just a hack on top of all the prior Microsoft Windows releases. While Microsoft Windows itself is just a hack on top the profoundly insecure and stunningly badly-coded DOS.

Considering the lousy reviews, it seems that Windows Vista is indeed "just a hack" on top of XP.

But it is no longer correct that it is a hack based on DOS. Parallel to Windows 9x, Microsoft introduced the Windows NT line. Windows 2000, XP and Vista are based on that.
In a direct comparison of Windows 2000 to Windows 98 (yes I've used both), Windows 2000 is a lot more stable, especially when confronted with bad applications. It is not perfect but definitely good enough for desktop use.
I'm using XP only occasionally, but it seems OK as well.
Vista - cough - no thanks. The reviews and personal accounts I've read are reason enough not to even try it. And the quality is only half of it, the EULA is even more inacceptable. Even if I strongly suspect it would be unenforceable in my country, I'd rather avoid getting anywhere near it.

Re:My understanding was that video runs in ring 3

[Foolhardy]

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 display driver arrangements: XPDDM, the XP display driver model, which is compatible with XP drivers (with the display driver in kernel mode like NT4), and LDDM (Longhorn display driver model) which has moved the display driver back into user mode, hosted in dwm.exe with the new desktop window manager.

There is a private interface for the display driver in user mode to communicate with the miniport driver in kernel mode. This is presumably where the ATI driver flaw is: the miniport apparently has a function to let the display driver read and write to arbitrary memory locations. Note that the caller has to be privileged to even open the miniport device object for communication. The flaw here allows a privileged user to bypass driver signing requirements.

For example, with nVidia's drivers, the XPDDM version has nv4_mini.sys as the miniport, and nv4_disp.dll as the display driver (kernel mode). The LDDM version has nvlddmkm.sys as the miniport and nvd3dumx.dll as the display driver (user mode).

The miniport has always been in kernel mode because it has to talk to the hardware. The display driver has gone from user to kernel and back to user mode.
Linux also uses a split kernel mode / user mode driver (in the X server) model.