Slashdot Mirror
Device Drivers Filled with Flaws, Pose Risk
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."
let's say there is a driver and it allows a buffer overrun to execute some attacker's code. Well to get to the driver the attacker has to first go through a user application. So there is a problem when the combination user application/device driver both have a problem validating the same input. I am not saying this is impossible, but it would be more unlikely - there must be a great coincidence at work here. Besides normally user applications do not pass user input directly to the device drivers. The user applications translate input from user form to some implementation specific device driver input. So more likely than not there is a layer of input transformation between the user and device driver.
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.
You can't handle the truth.
That's sort of the point of the ancestor post. Some drivers do not do that and are succeptible to the attack.
Atlas stands on the earth and carries the celestial sphere on his shoulders.
My experience is limited as well, but I would assume there's some facility not unlike SETUID.
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).
I've always tried to buy hardware which is supported by default in Windows - since XP-SP2 added a bunch of new drivers this has got a lot easier.
My reasons were so that a reinstall is a simpler affair, but it appears I may have been reaping security benefits too...
I have been a user for about 10 years. This ends Feb 2014. The site's been ruined. I'm off. Dice, FU
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.
If you mod me down, I shall become more powerful than you could possibly imagine.
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.
I'm sick of following my dreams - I'm just going to ask them where they're going and hook up with them later.
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.
"Can you do it without shutting down X, and all running X applications? Is that really so different than than a reboot?"
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.