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

Comments

That's why microkernels are useful

[Anonymous Coward]

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

[A non-mouse Coward]

Mod Parent Up.

Even Microsoft Research is looking into making microkernel operating systems with their Singularity project.

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

The major design factor of Microkernels 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. 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, for controlling access to critical areas of memory.

Of course, critics often complain about Inter-process Communication (IPC) 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.

Rules of the Road

[mfh]

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!!!!!

Re:lol wut

[fuzzix]

We need to strip ATi of its driver team, and then strip nVidia of their hardware team, and merge the remainder.

What does it matter? Neither of them bother with proper overlay any more.

My last nVidia card was simply without overlay hardware. My last ATi card's overlay dropped resolution when a high refresh rate was used. At least the nVidia card could play a video at full res without resorting to GL.

It's not all about the 3D... :)

You do have a point about the drivers, though. While closed, nVidia's Linux module hasn't provided nearly as much heartache as ATi's... abomination.

My understanding was that video runs in ring 3

[NullProg]

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

So what did Microsoft gain with the Vista GDI changes?

Enjoy,