Root Exploit For NVIDIA Closed-Source Linux Driver
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."
You beat me to it. This is now 2 (or 3?) exploits thanks to binary blobs that OpenBSD is immune to.
Trolling is a art,
There is already a 9625 beta driver available in nvidia's nzone.
From the actual advisory:
/. summary.
"This bug can be exploited both locally or remotely (via a remote X client or an X client which visits a malicious web page)."
That part wasn't in the
Learning HOW to think is more important than learning WHAT to think.
Apparently, the bug/exploit was fixed in the 9625 beta release. http://www.nzone.com/object/nzone_downloads_rel70b etadriver.html
09:F9:11:02 - 9D:74:E3:5B - D8:41:56:C5 - 63:56:88:C0
https://bugs.freedesktop.org/show_bug.cgi?id=3654
"The "nv" driver currently can't change the BIOS-programmed display timings. Unfortunately, this is not something that we can fix right now."
This just sucks, IMHO.
The problem is not that a root exploit exists. Shit happens. Those can be fixed and the world moves on.
The problem is that all users of Nvidia graphics cards are helpless to make their machines safe because Nvidia has control over the source code. If Nvidia says 'Screw you' or goes bankrupt, then their users are screwed. Had they GPLed their driver, then someone else could have fixed it.
And that's exactly what's happened in this case.
If you read the TFA, you'll see that NVidia has known about this bug for TWO GODDAMN YEARS already and NOT fixed it. Surely that's one big 'SCREW YOU' to the Linux, Solaris and BSD communities right there.
http://www.nzone.com/object/nzone_downloads_rel70
as well as the 1.0-9626 QuadroPlex driver:
http://www.nvidia.com/object/linux_display_ia32_1
http://www.nvidia.com/object/linux_display_amd64_
Thanks
They might want to play video games.
The drivers on that page are "BETA". Not released.
It is interesting that when someone holds back the disclosure of a vulnerability in Microsoft software they are praised for practicing "responsible disclosure", but when these Rapid7 people do the same they are accused of foaming at the mouth needlessly since a fixed driver is allegedly already released.
The exploit involves executing C code which uses the buffer overflow to replace the address of the free() function in your running copy of Xorg. I'm not saying it's impossible, but how is a web page going to make a Linux web browser execute arbitrary C code? ...
OK, I read a bit further, looks like you just need to create a malformed glyph in an embedded font. Not at all difficult to do with Java, Flash, or just plain HTML (or so I've heard, never seen an embedded HTML font in the wild). Damnit. Back to eLinks for me!
Karma: Incomprehensible (Mostly affected by posting at +5, reading at -1, and metamoderating everything unfair.)
The argument goes that a driver developed specifically for Linux is a derived work of the Linux kernel, and thus is subject to the conditions of the GPL. IANAL, but it seems to be a fairly sound argument. There is an explicit waiver for the standard user-space interfaces (so applications are not automatically considered derivative works), but no such waiver exists for the Linux-specific kernel interfaces. nVidia gets around this by (a) using an open-source wrapper, so their real driver doesn't use any of the Linux kernel interfaces directly, and (b) using the same driver code on Linux and Windows (so the driver isn't entirely dependent on Linux).
This has nothing to do with whether there is aggregation or dynamic linking, and everything to with whether the module is dependent on the GPL'd kernel API.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
I have never gotten dual-head support
out of the OS nv driver; the nVidia
closed-source drivers work for dual
head workstations.
As has been mentioned, why get an nVidia
card for your server? And this may be a
moot point for single-user workstations.
But do not assume that the nv driver is
a panacea.
"Never bullshit a bullshitter" All That Jazz
Exactly. Why is it that people assume that Linux users aren't gamers? Some play mainstream games under emulation. My partner is a gaming nut who loves all of the free games you can get with apt or yum. And despite the common perception, there are a lot of fun Linux games out there.
You're treating a symptom while the disease rages on. The fish rots from the head. Why not cut off the head?
The nouveau project is actively working on a free software driver for nVidia cards that will hopefully replace the nv driver one of these days. They could use some help.
http://nouveau.freedesktop.org/wiki/
http://wiki.x.org/wiki/nv
Quite often, something free is worth what you paid for it. nVidia has absolutely first rate drivers and while it's nice to think that there's millions of talented driver writers out there just waiting for a chance to make good drivers, that's just not the case. Writing good drivers isn't easy, that's one of the reasons nVidia is so popular with many is their top notch team does such a good job of it.
Also, they just can't. They have licensed code in their drivers that can't be opened up. Want real OpenGL? Well than you takes what you gets. OpenGL isn't free to hardware developers. It's $25,000 to $100,000, plus royalties for distribution and it does come with terms and conditions on it's release. There's also licenses on patented code like S3TC in there.
Now if the Linux community wanted to develop their own graphics API that was unencumbered, then maybe you could convince the companies to open their code up. However if you want a full featured GL driver, you are going to need to deal with closed source, at least form nVidia and ATi since they've both already signed licenses on it.
>> It's also the version without GL support. Without GL support you might as well have a Mach64 in there.
:-)
Well since you mention Matrox, get their G550 which has both GL support *and* open drivers.
The Matrox G550 PCIe card works perfectly with the pure open-source mga driver that comes as standard with all recent kernels. I've been using it in my Dell 2800 server, and its record of reliability is 100%.
Matrox even boldly proclaim their Linux source driver support on the box. That's quite unusual!
The card also has the distinction of being the only graphics card in existence that can run in a PCIe slot of 8 lanes or fewer, as it's a 1-lane card (all other PCIe graphics cards use 16 lanes), which means that it will work in traditional "server" chassis that tend to have 1/2/4/8-lane PCIe only.
And it's cheap and fanless too! I'm pretty impressed with it.
Unfortunately you will also have no multi-monitor support and no VBLANK synching. This means no HTPC and no dual-screen setups.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
The OpenGraphics.org project will release a 3D OpenGL enabled graphics card with full specifications and schematics so that FOSS developers can write open source drivers for Linux and BSDs. The consumer graphics card (code-named OGA) will be release after a development board (code-named OGD1) is produced. The key step is to make enough revenue (around $2 million) from selling the multi-function development board to fund the mass production of the consumer card.
Unless there is a wealthy individual / corporation out there who is willing to invest in order to manufacture this card earlier. The FOSS-friendly card will surely have a big appeal in Linux circles.
I run 4 systems with cards ranging from a geforce2 gts, to a 7800gt, and i've never had an issue other than when the 7800 just came out the drivers didnt much like it yet, but was fixed shortly thereafter. I play games that range from quake1 technology to bleeding edge, quake4 types of engines.
That version seems to have come out of beta 3 days ago:7 8188. 0-9626.html
http://www.nvnews.net/vbulletin/showthread.php?t=
http://www.nvidia.com/object/linux_display_ia32_1
It's also the version without GL support. Without GL support you might as well have a Mach64 in there.
And dual-head.
I have just installed NVIDIA-Linux-x86-1.0-9625 and it seems ok so far. I've visited a few of the troublesome links with firefox 1.5.0.7 and it's not crashed X yet. I was using NVIDIA-Linux-x86-1.0-8762 before the update, and several times I've had X crap out on me. I don't believe I was r00ted though, after reading about the glyph problems. It can also be triggered by a long "get" request, or long lines of text in a form field. I was using TinyMCE when it first happened to me. Here's a test url that supposedly crashes X from firefox - http://comptune.com/calc.php?methos=POST&base1=10
I didn't check this before the update though, so it may not be conclusive.
My main complaint about the whole issue is that I only found out because it was posted here. I don't have time to go checking for updates and exploits for all my different drivers and software, that's why yum runs from cron every night. It would have been nice if somebody (nVidia) had posted that a new version was available that fixed potential security holes, or even had a version checker built in to notify me of an update.
"The drivers on that page are "BETA". Not released."
Well, the "nv" drivers not only aren't beta, they are prealpha and prehistoric as they don't have any kind
of hardware acceleration. still the beta 9xxxx drivers are a better workaround (and they're already in use
in all the bleeding edge systems because of glx_texture_from_pixmap support : compiz/beryl without need of XGL)
...the best that an attacker can accomplish is a DoS for as long as you are visiting that site...
s p?url=';a='a';i=18;while(i--)a%2B=a;location=a;//
Then perhaps you can explain why this isn't a working javascript exploit proof of concept:
(Taken from a post further down this very page)
http://nvidia.com/content/license/location_0605.a
I mean... if the overflow is that easy, wouldn't someone adept at hitting the right targets in memory be able to do a lot worse with nothing more than javascript?