ATI Driver Flaw Exposes Vista Kernel to Attackers 248
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."
That's why microkernels are useful (Score:3, Interesting)
Kernel Type (Score:2, Interesting)
Rules of the Road (Score:4, Interesting)
YOUR VIDEO CARD NEEDS NEW DRIVERS: CLICK NEXT!!!!!
Re:Let's blame Microsoft (Score:1, Interesting)
See, MS said this wouldn't be an issue. Specifically this. Regardless whether ATI has an issue, the Vista kernel shouldn't sign something that can be modified, without the signature changing.
Re:lol wut (Score:5, Interesting)
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.
Linux fglrx module possibly also exploitable (Score:2, Interesting)
I always wondered if this could be turned into a more dangerous security exploit. And now I wonder how much code is shared between fglrx and the Windows driver, as it seems it has similar bugs.
My understanding was that video runs in ring 3 (Score:4, Interesting)
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-578
So what did Microsoft gain with the Vista GDI changes?
Enjoy,
Re:That's why microkernels are useful (Score:4, Interesting)
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:Let's blame Microsoft (Score:3, Interesting)
It is a lot easier and more reliable to test a driver for stability than it is to test it for security. There is so much crap hardware with flakey drivers floating around which causes stability problems, Windows has an undeservedly bad reputation for stability. Everyone blames Microsoft when the see a BSOD, but in many cases they should be blaming the manufacturer of their $10 SATA adapter.
I'm posting this from an Ubuntu box, so I'm no MS apologist. But Windows' reputation for being unstable is greatly exaggerated. Signed drivers may help correct this particular market perception.
Re:So I read it right? (Score:3, Interesting)
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 and hardware initialization are taken care of, leaving a kernel to worry about the more interesting things. As one hacker says, "on x86, it just works!"
http://www.open-mag.com/features/10_02feats/HAL/H
Re:Let's blame Microsoft (Score:1, Interesting)
Then, sir, you're easily amused.
An OS's kernel needs access to stuff not even an admin should touch. Direct low level access to hardware, some special CPU ops, direct memory management, CPU scheduling, etc.
Re:Break the signing (Score:3, Interesting)
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 statement like the one you made imply.
It does have the advantage of all the failure points being reviewed by one source (MS) that can be improved over time to catch attacks like this. They obviously are not yet perfect, but it's a marked improvement. But still, how many holes are found by people who aren't honest security researchers? How many people get patched? We have no way of judging the safety of the system, nor if its improvements are increasing at a sufficient pace.
Re:That's why microkernels are useful (Score:3, Interesting)
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 I bet we're doing a fair number of things _wrong_.