An individual instance of a given buffer overflow exploit in a device driver in and of itself is not really a bigger risk on Windows. It just seems to be a more common design pattern on Windows systems, thus creating more opportunities for exploit. (Several fine examples of questionable use of device drivers, and some associated known vulnerabilities are discussed by others here).
The referenced article at Security Focus points out that inspection of device drivers in Linux revealed similar defects in device drivers.
Device drivers are more interesting than user land software because they run in kernel space, allowing the exploit to be immediately useful to perform nasty things like install rootkits and trojans, log keystrokes, etc.
Good point. However, it doesn't need to be easy, it just needs to be easy enough for one sharp cracker to figure it out.
Today there are literally thousands of variants different worms exploiting dozens of different buffer overflows. Most of them are derivative, relying on published source code produced by one person, and sometimes on a toolkit. If there are dozens or hundreds of buffer overflows in commonly used device drivers, they will get discovered and some of them will be exploited. Some of them might be exploited already by crackers with goals other than using worms to create fleets of botnets.
Well, that's really not a good way to tell. AltiVec is often used to accelerate features that also need to work, albeit less quickly, on machines without AltiVec.
Probably not. Carbon is just a C based API, and Carbon applications would be recompiled, too. It would probably be a bit more work, but there is no reason they would need to be emulated and run slower.
A different, somewhat less problematic approach has been used by
Artists Against 419
They link to images from 419 web sites to slurp their bandwidth which often shuts them down for a while when they exceed bandwidth limitations imposed by their hosting provider.
Slashdot Mirror
An individual instance of a given buffer overflow exploit in a device driver in and of itself is not really a bigger risk on Windows. It just seems to be a more common design pattern on Windows systems, thus creating more opportunities for exploit. (Several fine examples of questionable use of device drivers, and some associated known vulnerabilities are discussed by others here).
The referenced article at Security Focus points out that inspection of device drivers in Linux revealed similar defects in device drivers.
Device drivers are more interesting than user land software because they run in kernel space, allowing the exploit to be immediately useful to perform nasty things like install rootkits and trojans, log keystrokes, etc.
Good point. However, it doesn't need to be easy, it just needs to be easy enough for one sharp cracker to figure it out.
Today there are literally thousands of variants different worms exploiting dozens of different buffer overflows. Most of them are derivative, relying on published source code produced by one person, and sometimes on a toolkit. If there are dozens or hundreds of buffer overflows in commonly used device drivers, they will get discovered and some of them will be exploited. Some of them might be exploited already by crackers with goals other than using worms to create fleets of botnets.
Well, that's really not a good way to tell. AltiVec is often used to accelerate features that also need to work, albeit less quickly, on machines without AltiVec.
If you would like to know more about AltiVec, here are a couple places to start:
AltiVec Document Archive
Search results for AltiVec at developer.apple.com
Probably not. Carbon is just a C based API, and Carbon applications would be recompiled, too. It would probably be a bit more work, but there is no reason they would need to be emulated and run slower.
A different, somewhat less problematic approach has been used by Artists Against 419 They link to images from 419 web sites to slurp their bandwidth which often shuts them down for a while when they exceed bandwidth limitations imposed by their hosting provider.