Root Exploit For NVIDIA Closed-Source Linux Driver 548
possible writes, "KernelTrap is reporting that the security research firm Rapid7 has published a working root exploit for a buffer overflow in NVIDIA's binary blob graphics driver for Linux. The NVIDIA drivers for FreeBSD and Solaris are also likely vulnerable. This will no doubt fuel the debate about whether binary blob drivers should be allowed in Linux." Rapid7's suggested action to mitigate this vulnerability: "Disable the binary blob driver and use the open-source 'nv' driver that is included by default with X."
useless suggestion (Score:4, Insightful)
This is as useless as suggesting "Install Linux" when a Windows vulnerability has been found!
Allowed? (Score:5, Insightful)
This will no doubt fuel the debate about whether binary blob drivers should be allowed in Linux.
Of course they should be allowed. How can that even be prevented? The more important question is what can be done to either provide more secure replacements or make sure binaries can be functional without having to be trusted by the OS.
To Theo de Raadt (Score:5, Insightful)
Re:useless suggestion (Score:0, Insightful)
Open vs. Closed yet again... (Score:2, Insightful)
I'm sure endless flame wars will follow below...so you guys have fun with that
Missing out. (Score:5, Insightful)
This is a relatively minor problem (Score:5, Insightful)
What we need is a graphics vendor who publishes full specs for their graphics chips! If nVidia won't do it, find someone who will.
Re:useless suggestion (Score:5, Insightful)
Quite useless. (Score:2, Insightful)
Also the ones without openGL performance. Remind me why I bought a high-performance 3D card again.
Can't get worked up (Score:4, Insightful)
Analyzing this, I think the reason is because the NVidia and ATI drivers are a PITA everywhere. By installing the drivers, you agree to destablize your system in exchange for the most incredible 3D (and 2D to a certain degree) performance. When Something Bad Happens(TM), you just sort of take it as coming with the territory.
It's sort of like hooking Nitro up to your car. Sure, your engine is more powerful than ever. But are you really all that surprised when you bust a valve, crack a ring, or do some other form of damage to your hotrod?
It would be nice if OSS drivers could be created. But it's probably not going to happen. NVidia won't open their drivers (ATI, doubly so) and the OSS community doesn't have enough info to recreate them. Thus I think the best bet is the Open Graphics Project [duskglow.com]. If they produce a viable 3D card alternative, you'll finally be able to chose between a stable (but slower) 3D card, or a high-performance, hotrod 3D Card. Take your pick to meet your needs.
Oh, and keep a firewall in front of your machine and the internet. Pipe all your X communications over SSH. Just good safety sense.
Re:Intel Open Source Graphics Driver (Score:3, Insightful)
It ain't too serious. (Score:5, Insightful)
How many people use the nVidia cards in their servers? None, I guess. nVidia, and most 3D-cards is used on personal systems, with one user, which is usually root. If that user can use a root exploit to become root - so what! Remember that you have to be able to control the X11 display server to take advantage of this, which means you *have* to be logged in locally or be root.
Whilst I agree with the principle, I don't think this bug will have *any* impact, as most home boxes have no accounts accessible from the internet, that is able to run X11. If they have, they probably have bigger problems. Same goes for people running untrusted code that can execute this: it could as well provide a shell, or whatever. Yet, the problem is then *untrusted* code. A person that runs untrusted code can probably be coerced into running that as root as well.
So my guess: zero impact!
So... (Score:5, Insightful)
Re:useless suggestion (Score:1, Insightful)
"Root Exploit For NVIDIA Closed-Source Linux Driver"
to
"Root Exploit For NVIDIA Linux Driver"
I'm personally tired of this over-zealous open-source push. Nvidia is a closed-source company, but they make good products. Stop villainizing Nvidia and evangilizing this open-source madness to everyone. I use Linux (Arch distro - go Arch!) and the hated "closed-source" driver from NVidia because THEY make their cards and THEY make the best drivers for them.
Anyone worried about open-source to this degree, just don't buy an NVidia card already. Trade secrets are money makers, and you can't definitively say that opening their source wouldn't give away some trade secrets or algorithms that keep NVidia at the cutting edge of video card production. If they took out those algorithms to appease a super-minority of NVidia card users, their card would perform sub-par.
I really can't believe this whole thing gets so much play.
Re:Allowed? (Score:4, Insightful)
The Nvidia blob is perhaps a special case, since it's really a windows driver with a GPLed wrapper, so the Linux community tends to turn a blind eye, as long as the driver isn't distributed alongside the kernel. Anyone trying to write a blob driver for Linux, from scratch, would be on shaky ground. Even Linus has said that if you wrote your driver with Linux in mind, it's a derivative work.
This is a grey area and there's not a lot of case law to decide exactly what is, and isn't, a derivative work in software, so a debate does occasionally flare up, most recently with the Kororaa livecd.
Re:Too bad Intel doesn't have open source drivers (Score:1, Insightful)
Your post is not even *remotely* based on facts:
Keith Packard - maintainer of X.Org is a fulltime employee of Intel, and works 100% on improving X.Org including DRI/DRM and all 3D graphics drivers (Including Intel's).
How much specs do you want if a fully working 3D-enabled Open Source driver is released???
None of the graphics components of the i965 chipset (and afaik other chipsets) need a binary blob. As a matter of fact, there are no binary blobs for Intel Graphics chipsets at all.
Shape up and get informed.
Re:How serious, really? (Score:3, Insightful)
Re:useless suggestion (Score:0, Insightful)
News flash: This wouldn't happened in an open-source driver:
Re:useless suggestion (Score:1, Insightful)
You're being encouraged to give all of your money to charities. You know, the people who REALLY need the money.
You can't honestly argue that you're the poorest person in the world, can you? Certainly, there's no denying that SOMEBODY needs your money more than you do!
What say, hmm?
What's that? People
(sigh)
Perhaps try asking yourself why nVidia even bothers making closed source drivers, since it seems apparent to you that the open source ones are much better and more secure. I mean, do you think Satan himself was born incarnate as a kernel developer for the sole purpose of heartlessly "inventing" the "closed source driver"? Or do you suppose it's a human phenomenon, and there's actually some reason and/or purpose behind it?
If you don't need the extra functionality/performance of the proprietary nVidia drivers, you probably aren't using them to begin with. There's corporate distros (Novell and RHEL), which come with the proprietary drivers... they probably already have patches for this. Then there's the free distro's that probably most people on here use on the machines with the nVidia 3D cards: Ubuntu, OpenSuSE, Fedora Core, Mandrwhatever, etc. These generally install open source drivers out of the box. Since you actually have to work to get the proprietary ones to work right (3D and all), it's likely that the people who use them probably need them.
You can see, then, how suggesting that people simply switch back to the OSS ones is truly "useless".
Why can't the world be as obvious to everyone as it is to me? Or are you just trying to be aggrevating/obnoxious?
Re:useless suggestion (Score:5, Insightful)
As far as I'm concerned, if you're a potential customer, a company damn well ought to listen to you if they want to sell their products. Open-source drivers are a feature that a lot of users want, whether to use cards on other architectures, to fix bugs sooner, to improve their performance, to audit them for use in security-sensitive deployments, etc.
Lots of users would *LOVE* to punish NVidia for not responding to their desire for open-source drivers, but they really can't... there's no good alternative. ATI drivers are closed-source as well, and that's the only other big player in 3D graphics cards. Now Intel has come out with actual real-live open-source drivers for their 3D graphics cards, and there's been a chorus of folks planning to switch over to them (even though they're rather underpowered compared to the NVidia cards).
NVidia may make pretty good drivers, but I bet they could be made a whole lot better and more versatile by open-sourcing them. I've encountered 4 or 5 NVidia driver bugs on my AMD64 box, and have NEVER found any bug in any other non-experimental open-source Linux device driver.
Re:To Theo de Raadt (Score:2, Insightful)
OpenBSD had a root level exploit in 2000.
Many applications that run on OpenBSD have had exploits in them including SSH.
Seems kind of harsh to bent all selfrightous over one exploit. I hope nVidia patches it soon.
Re:useless suggestion (Score:3, Insightful)
The one "acceleration" that the X.org 2d desktops use is mostly render (for doing font AA, etc). But the X.org 2d drivers can provide that without using kernel drivers.
The propietary module provides you a alternative and propietary 2d driver, but's its possible to use the nv one, which was written also by nvidia i think. I don't know if it supports the render extension, but it certainly allows you to use your desktop without toouching the binary crap, even if it's a bit slower.
Re:useless suggestion (Score:3, Insightful)
Re:useless suggestion (Score:3, Insightful)
Re:Allowed? (Score:2, Insightful)
I don't see how that can ever be the case.
If I distribute something (closed source) that is dynamically linked against a certain GPL library, but I never distributed any GPL code, the GPL doesn't apply to me for that work, I need no authorization to distribute something that merely can potentially utilize a GPL program in a closely tied way.
Distributing the two together in any way would violate the GPL, such if they were statically linked or offered together.
Re:Allowed? (Score:1, Insightful)
1) A HW vendor is (naturally) perfectly entitled to write a Windows or generic driver blob.
2) A "third party" could write a kernel/blob interface.
3)
4) Profit!
There is no way that blobs could be "banned" from interoperating with the kernel - I don't think they can be considered a "derivative work" because really they add functionality to the kernel, not take functionality from it - besides there's too many other backdoor ways of getting round it.
So, rather than just making a sensible, stable, driver ABI we have something not stable which doesn't support binaries. It's just a PITA to have to recompile all the bloody VMWare drivers every time a slightly revised kernel comes out. This is the kind of thing that just hurts users without doing anything to the vendors which it is meant to spite.
It makes me think of the kind of DRM that prevents users from playing their music whever they want to but doesn't stop the pirates at all.
When people witheringly quote the "You have moved your mouse: Windows must reboot to complete this operation" type quips I tend to think "You have moved your mouse: Linux must recompile the kernel and all your third party modules to continue".
I would _much_ prefer all drivers to be Free and would buy such in preference to other hardware, but in absence of anything like real functionality I'll grudgingly compromise.
Possible remote exploit vector (Score:5, Insightful)
Re:useless suggestion (Score:3, Insightful)
Re:Allowed? (Score:3, Insightful)
Adding functionality has nothing to do with copyright law. If you don't believe me, add some binary-only functionality to gcc or emacs and see how long it takes for Eben Moglen to get on your phone.
"besides there's too many other backdoor ways of getting round it"
Well you can shift your blob down into firmware or up into userspace. I think the kernel devs would be happier with that than with you tainting their kernel.
"So, rather than just making a sensible, stable, driver ABI we have something not stable which doesn't support binaries. It's just a PITA to have to recompile all the bloody VMWare drivers every time a slightly revised kernel comes out. This is the kind of thing that just hurts users without doing anything to the vendors which it is meant to spite."
If youre recompiling drivers, then you should be asking your vendors to put the drivers in the kernel, where all the maintenance and interface twiddling gets done by the kernel maintainers. It also means the kernel people can revise and twiddle the interface when they feel like it, instead of turning the kernel into a mush of backwards compatibility kluges like windows. The kernel writers have looked long and hard at what happens when you encourage binary only drivers, on the lkml, and they have their reasons for keeping it the way it is. Check it out here [google.co.uk].
You guys like to think you're making pragmatic compromises; you're making foolish short-sighted mistakes. Look at THIS case, where a known bug has sat in a video driver for 2 whole years and counting...
Re:useless suggestion (Score:2, Insightful)
Re:Open vs. Closed yet again... (Score:2, Insightful)
Sure, just as soon as you find a video card company that has open driver programming documation and specifications... I really hope AMD will open ATI's documation and Linux driver up... at the very least not require an NDA for the documation already available.
A tale of two drivers: Closed and Open (Score:3, Insightful)
Re:To Theo de Raadt (Score:3, Insightful)
And that's the problem. The fact that people have been complaining about this for two years, and havn't even put together a binary patch for it, suggests to me that the "we don't have source" argument, although valid, is just an excuse for making yourself a victim. I wish I had heard about this two years ago because I would have made a binary patch and made sure everyone knew they had to install it. But I guess that's what you get when you don't participate in Full Disclosure.
Re:It ain't too serious. (Score:3, Insightful)
Because an exploit for *any* software you run has full access to your system? If you run as root, the cracker merely needs to alter the execution of your program and they're in with full priviledges.
If you don't run as root, they have a far smaller selection of programs (basically daemons or drivers) that will potentially get them remote/full access if exploited.
How about you turn the question around. Why run as root? You don't need it for 99.999% of tasks, and instead of spending time worrying about what you'll clobber every time you do something as root, spend the 5 seconds typing sudo xxx and your password if you need it?
I've always doubted the 'trade secrets' argument (Score:3, Insightful)
I mean, it's not like anyone out there actually has a disassembler or anything. If there was anything worth digging for in their binary drivers, someone would have disassembled that bit and posted it as code already.
Re:useless suggestion (Score:3, Insightful)
No-one here is under the illusion that NVIDIA will open their drivers because someone on
Local escalation (Score:3, Insightful)
If you follow best practices, you'll probably end up with a system where any vulnerability only leads to access as a user. But when there are local root exploits available, you can escalate that user access to root access and hide your rootkits there.
So with this Nvidia bug, the real risk is that another service gets compromised and the attacker then uses this exploit to get root. Once they have root, they can install rootkits, etc.
Re:useless suggestion (Score:3, Insightful)
I don't think you understand how this exploit works:
This exploit cannot be remotely executed. It requires a user to be logged into their account on the machine they want to infect. In other words, for those of us with linux workstations (only one user account), this exploit doesn't affect us at all.
The only type of machine this exploit targets are machines with multiple untrusted user accounts. I can't imagine why someone would be running this NVIDIA graphics driver on a server type machine anyway...
With all that in mind, it is highly unlikely that anyone would be able to maliciously use this exploit. However, I would like to see NVIDIA fix this problem.
Re:To Theo de Raadt (Score:3, Insightful)