Device Drivers Filled with Flaws, Pose Risk 189
Gary W. Longsine writes "Security Focus describes device drivers as an untapped source of buffer overflows, posing substantial risk not typically considered as part of a standard risk assessment. The security risks of device drivers on both Windows and Linux, including network (remotely exploitable) and hardware drivers (typically only locally exploitable) are discussed in the article. I've noticed that software you wouldn't expect sometimes installs a device driver component. I can understand this as a component of an antivirus or host based firewall, but it seems to be an oddly common design pattern on Windows, which clearly poses substantial risk."
not that easy (Score:5, Insightful)
Now to go around this problem the attacker may need to get the user to execute some code on the machine and this could mean that if the code is executed - even on a Linux box for example, and the code exploits a device driver flaw, due to the monolythic kernel structure of Linux it is in principle possible to execute code that will say change user privileges to admin level. I guess this would be much more difficult with a microkernel approach like what Hurd is supposed to be, because even device drivers will run in managed memory mode.
Re:One hardware driver one from way back. (Score:4, Insightful)
Re:Why is this a bigger risk on windows? (Score:1, Insightful)
That aside, though, there's a lot of poorly-written software out there, even from the big boys, that can't properly handle restricted user accounts and requires you to log in as an administrator. It's quite daft, but that's the world of Windows (and, in some cases, Windows developers porting to Mac OS and Linux).
Re:not that easy (Score:2, Insightful)
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.
"Built For Windows" (Score:3, Insightful)
My reasons were so that a reinstall is a simpler affair, but it appears I may have been reaping security benefits too...
Re:Why is this a bigger risk on windows? (Score:4, Insightful)
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.
Re:ugh (Score:3, Insightful)
Now, I'm not saying that hackers will go and start fixing open source drivers just cause they're there, some will, but it is not something to count on. I am saying that crackers will go into that code and find the problems and start using them.
Once the bad guys see how something works exactly they can set up exploits much more rapidly - causing the code's maintainers and architects to fix these flaws both minor and major.
Do you not think that if drivers were open sourced we'd see a much more rapid developement of exploits and subsequent fixes?
This increased rate of reaction would in the end lead to a more mature and secure driver set; although for a time it would likely be hell for system administrators and home users.
Re:ugh (Score:3, Insightful)
Certainly, no reasonable person will suggest that if you make some horrible software, putting the source on an ftp server will magically cause it to work perfectly, or all the bugs to be instantly found. Open source software does, however have some merits.
Suppose a team is trying to track down a bug in some software they wrote, but they can't find it. Everything looks right. Well, then that's pretty much it. They just keep looking. With open source, you have a chance that some random stranger will approach a problem with a fresh set of eye balls, and ask, "What the hell were you smoking!!??!!" I know I have been immensely helped by having a friend looking at my code, and he has been immensely helped by having me look at his. Whenever some 3rd party can look things over, he isn't emotionally attached to early design decisions, and he hasn't already convinced himself that something is correct. The only was to do that with proprietary software is to bring in a consultant. That's usually expensive, and it would be embarassing to the devs if he found major problems.
Another advantage to OSS is that knowing your code will be seen by others forces you to be a bit less likely to name your variables bob and fish, and freddybob. Obviously, no proprietary developer should do anything like that, but we have all gotten caught up in trying to make a prototype, knowing about the weaknesses of the prototype, realising the schedule is short, and declaring the prototype "good enough." You try to convince your boss you need more time to do a proper rewrite, with an extensible architecture that will better accommodate growth. He says tough banannas. Then, you wind up trying to bolt on the features for version 2 and 3, onto what was supposed to be just a prototype. Madness ensues. Whereas, doing a public release from day 1 means you would be embarrassed if people saw your prototype, so you are a little more likely to try to do it right.
So, yeah, I agree with you that zealots have to much faith in OSS, and probably unjustified criticism of proprietary software, but on even footing, with competant developers on both sides, the ability of OSS to leverage more "outside proofreaders" does suggest that it has the potential to be a bit higher quality on the average. Not perfect. Not always better. But, still, not a bad idea.
Re:Design pattern (Score:3, Insightful)
It's very much different than a reboot. My system keeps running, but the 'paint job' stops. You could have other processes in the background doing their job (like copying files in another shell or whatever) while you do the update. You unload the old kernel driver, load the new one, start X back up.