Slashdot Mirror
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."
if each driver had its own separate space, this flaw wouldn't affect the rest of the system.
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?
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!!!!!
The dangers of knowledge trigger emotional distress in human beings.
hi troll.
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.
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.
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 =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 fglrx and the Windows driver, as it seems it has similar bugs.
Oops, I guess not....
8 .html
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,
It's just the normal noises in here.
I think Microsoft's main consideration with driver signing is stability, not security.
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.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
udev is part of the Linux kernel project, while HAL and D-BUS are not.
A L.htm
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
Having to work for a living is the root of all evil.
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.
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 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.