Linux: NVIDIA Binary Graphics Driver Exploit

Submitted by Jeremy
on October 16, 2006 - 12:47pm

A recent security advisory announced today by Rapid7 explains, "the NVIDIA Binary Graphics Driver for Linux is vulnerable to a buffer overflow that allows an attacker to run arbitrary code as root. This bug can be exploited both locally or remotely (via a remote X client or an X client which visits a malicious web page). A working proof-of-concept root exploit is attached to this advisory." The advisory goes on to note that the FreeBSD and Solaris binary drivers are also likely vulnerable to the same flaw and cautions, "it is our opinion that NVIDIA's binary driver remains an unacceptable security risk based on the large numbers of reproducible, unfixed crashes that have been reported in public forums and bug databases."

Chad Loder [bio], Rapid7's Manager of Engineering, explained that NVIDIA has known about this bug in their binary driver for some time, "the link in the advisory is the earliest thread in which we could find an NVIDIA employee publicly acknowledging the bug, although it was reported back in 2004 and has probably existed even longer." Regarding the decision to announce the exploit to the public Chad explained, "I expect (or hope) that NVIDIA will fix the defect in their binary drivers quickly. I don't know anything about their development process or where their Linux drivers fit into their priority list. It seems that the majority of Linux users are perfectly willing to accept bugs in binary blob drivers from hardware vendors, so there is little incentive for NVIDIA to change their process."

The OpenBSD project has frequently warned against the inclusion of binary-only blobs in otherwise open source operating systems, making this problem the theme of their 3.9 release. In recent KernelTrap interviews with Theo de Raadt [interview], Jonathan Gray [interview] and Damien Bergamini [interview], much discussion was made of the potential security problems inherent in using binary blobs. In regards to the current exploit, the security advisory suggests disabling NVIDIA's binary blob driver and using instead the open-source "nv" driver that is included with X.


Related links:

NVIDIA released the 1.0-9625

Anonymous (not verified)
on
October 16, 2006 - 1:22pm

NVIDIA released the 1.0-9625 driver which fixes this bug last month:
http://www.nzone.com/object/nzone_downloads_rel70betadriver.html

Its a bit ironic how these Rapid7 guys are foaming at the mouth about NVIDIA's awareness of the issue when Rapid7 wasn't even aware that its been fixed for weeks now.

Wow, so it only took NVIDIA 2

Anonymous (not verified)
on
October 16, 2006 - 1:29pm

Wow, so it only took NVIDIA 2 years to fix this bug, yet it's only fixed in a beta driver (did you confirm that it's fixed?). If you still trust NVIDIA enough after this to run their beta, you should have your head examined.

Since you are obviously so co

Anonymous (not verified)
on
October 16, 2006 - 4:19pm

Since you are obviously so concerned about such a heinous security hole, you must have some real-world examples of computers that have been compromised using this exploit, no?

Don't be such a douche. Of

Anonymous (not verified)
on
October 16, 2006 - 6:00pm

Don't be such a douche.

Of course it's true. Didn't you notice that there is exploit code running around on the internet right now?!! Run it for yourself if you don't beleive it.

Do you think these people are blowing smoke up your ass or something?

And it _MAY_ be fixed.

The kernel code could been changed enough that the exploit won't work anymore, but that doesn't mean that the actual security flaw has been fixed properly. You notice that with Windows patches would fix a 'hole' then a week later a new exploit is released that attacks the same flaw successfully from a different direction.

I know that you think that Nvidia is important to Linux and all that, but it's reality that closed source drivers are a threat to the security of your system. Open source drivers have problems also, but no known buffer overflow in a popular kernel driver would of lasted almost 2 years.

fix it, don't hype it

postmodern (not verified)
on
October 16, 2006 - 6:14pm

Most Linux distros are pre-configured to not listen on a TCP socket for remote X session requests. Furthermore, most distros that ship with services enabled by default have them bound to the localhost interface, making remote access to them impossible.

Therefor, this vuln is primarily local. We should be concerned about this and upgrade immediately to the beta driver which fixes this buffer-overlay/privilege-escalation. But this vuln is being over hyped, trying to make it into that sshd vuln that came out around 2002.

Here is nice special link the

Anonymous (not verified)
on
October 16, 2006 - 6:53pm

Here is nice special link the authors of the advisory have shown a few people who say this "this vuln is primarily local".

http://nvidia.com/content/license/location_0605.asp?url=';a='a';i=18;while(i--)a%2b=a;location=a;//

(hope the URL does not get munged)

Oh my!!! The link you posted

Anonymous (not verified)
on
October 16, 2006 - 10:38pm

Oh my!!! The link you posted (http://nvidia.com/content/license/location_0605.asp?url=';a='a';i=18;while(i--)a%2b=a;location=a;//)
is a link to the exploit: my X server crashed! I'm running 1.0-8774. My screen turns into black and white fuzz and the system is non-reponsive: this exploit is very real! This happened to me on another website about a month ago, and I couldn't figure out what was causing it...Now I know!

That is awesome. Or not as t

Anonymous (not verified)
on
October 16, 2006 - 10:38pm

That is awesome. Or not as the case may be. I can confirm clicking on that link kills the X server. It sits there for a bit, then the firefox could not render page comes up and almost immediatly the X server crashes and I am presented with the login screen.

This bug could be exploited to do whatever by just visiting a web page!

Do _not_ open this url, read

Anonymous (not verified)
on
October 16, 2006 - 10:39pm

Do _not_ open this url, read it carefully and you'll see it's a nasty trick.

Can someone who is not runnin

Anonymous (not verified)
on
October 16, 2006 - 11:01pm

Can someone who is not running the nvidia closed source drivers capture this exploit (from the link above) to verify its exsistence and log this event properly?

It's not NVidia specific, rat

Anonymous (not verified)
on
October 17, 2006 - 12:06am

It's not NVidia specific, rather a bug in Firefox - it crashes when running on X with ATI open-source driver too.

It is the NVIDIA bug

Anonymous (not verified)
on
October 17, 2006 - 12:24am

It is the NVIDIA bug. Firefox without the NVIDIA blob simply displays 'Document contains no data' without any incident. Yes, I tried. Did you?

It's not NVidia specific, rat

Curtman
on
October 17, 2006 - 5:06am

It's not NVidia specific, rather a bug in Firefox - it crashes when running on X with ATI open-source driver too.

It didn't crash mine. FF 2.0rc3, Xorg 7.1.1, "radeon" driver.

Works for me.

Anonymous (not verified)
on
October 17, 2006 - 10:10am

All that happened when I clicked on the link is a short delay and then the URL bar got a long black line through it and the page displayed a "the connection was reset" error. I'm using a fedora core 5 system with firefox 1.5.0.7, and an Intel motherboard video card and open source drivers.

No, it doesn't crash with the

Anonymous (not verified)
on
October 19, 2006 - 2:39am

No, it doesn't crash with the open source radeon driver.

Ahem, I'm using the latest nv

FiNex (not verified)
on
October 17, 2006 - 1:47am

Ahem, I'm using the latest nvidia driver (8774) and I've followed that link without crash (with konqueror, I haven't firefox installed)

*Yawn* I followed the link an

Ben Axnick (not verified)
on
October 17, 2006 - 5:29am

*Yawn* I followed the link and as suspected I ended up with a load of 'a's in the taskbar, resulting in - you guessed it - a page not found error. I'm using Konqueror and have the latest non-beta Nvidia binary blob as well as firefox installed on my system.

Is anyone sure that is the Nvidia exploit or just some random firefox exploit?

not new and not just nVIDIA

Bbt (not verified)
on
October 17, 2006 - 5:15am

Sorry, but this link not a real nVIDIA exploit...
It's compromitted me with intel chipset and ATI chipset too, on Linux., with Xfree86, and Xorg too...

Even so, it may demonstrate h

Anonymous (not verified)
on
October 17, 2006 - 3:24pm

Even so, it may demonstrate how there are remote exploits that you can now promote to remote root exploits.

Wow, does no one seem to care

Anonymous (not verified)
on
October 18, 2006 - 4:07am

Wow, does no one seem to care? That was (or maybe still is, im not going to try it again) a link to a live firefox, nvidia, or X11 exploit... I sent firefox a message from the "report broken website when I found another website which did the same think as the link to my computer. I even posted about it on firefox forums, and no one replied! I expected better from the open source community.

This is the wonderful thing a

Anonymous (not verified)
on
October 20, 2006 - 1:25am

This is the wonderful thing about the open source community. Everybody gets to be some kind of bastard idealist and blame another project and refuse to fix their own bug on those grounds. Oftentimes you'll see it argued that doing serious harm, like causing data loss, is better than making software resilient against external misadventure, simply to force the issue with other developers.

Nobody facing serious commercial pressures is going to risk being such a prat.

Strictly there must be a bug in the X server. Evidently some component common to several of them. We know this because the server should never crash, no matter how stupid the application's request is. That means it's none of Firefox's business.

Chances are, though, that Firefox is doing something pretty stupid to get into that situation in the first place.

So you don't think an

Anonymous (not verified)
on
July 23, 2008 - 1:04pm

So you don't think an application can kill an xserver?
Ever heard of the 'kill' command?
You think Xorg should ignore the 'kill' command, or any other application trying to kill it, somehow?

You sir, are an idiot.

Xorg may have a bug, but this isn't the case here.
Firefox is clearly the issue.

No, because your suggested

Anonymous (not verified)
on
August 12, 2008 - 6:41am

No, because your suggested kill command will not in fact kill the X server, but return "Permission denied", unless you are running as root in which case you sir are in fact the idiot rather than the GP.

Awesome - killed my machine for good

Anonymous (not verified)
on
October 20, 2006 - 9:43am

Clicking this link in firefox as a non privileged user on an nvidia-driver X11 session caused the monitors to go black and it killed the motherboard. The power button now has no effect ... Really interesting.

For reference, the motherboard is an ASUS A8N-SLI Premium.

Awesome!

doesn't crash here

Anonymous (not verified)
on
October 28, 2006 - 11:08am

I visted the link and firefox showed a "connection reset" page, some binary garbage appeared in the URL field, and ff seemed unresponsive for a moment. I hit the back button, returned to the kerneltrap page, and rock on. So yeah, they've already fixed the driver - I'm running 1.0-9626 here.

BTW The vulnerability is not the one reported in 2004, as the mudslingers have been screaming. They confused this recent and short lived nvidia exploit with an old xorg exploit. This nvidia vulnerability existed in 2 versions of the driver only.

at least here nothing happened

theclaw (not verified)
on
November 1, 2006 - 10:16am

the link didn't do _anything_ here, tried it with Firefox 1.5.0.7 and Opera 9.02, with nvidia-8774 drivers. firefox simply said that the script is busy and asked me whether i wanted to kill it (which i did), opera simply did nothing. (yep, javascript enabled)

bye,
theclaw

I asked if you knew of any co

Anonymous (not verified)
on
October 16, 2006 - 10:12pm

I asked if you knew of any computers that had been compromised by this, and you're telling me "run it yourself", which kind of illustrates my point, doesn't it?

To compromise your PC it requires you to run something locally OR

It requires a user to allow external X clients to connect to the X server AND it requrires shell access for the attacker to gain info about memory locations so that the hostile X client will know where to insert the malicious code.

I'm not saying that it's not a problem, or it shouldn't be fixed (though it apparently has been now) but I am saying that it isn't the catastrophic security threat that the "OSS Uber Alles" folks are wishing it to be.

That "security advisory" was an Op Ed piece denouncing the evils of closed source drivers. And much like your hostile ranting on the same subject, it does more to discredit your cause than serve it.

If you are using the nvidia d

Anonymous (not verified)
on
October 17, 2006 - 4:45am

If you are using the nvidia driver in a school for example where a large number of students have access to the computers it might be a large problem if someone has root access to the computer and install a keylogger, rootkit or whatever...

I actually am, and could not

Jani Jaakkola (not verified)
on
October 18, 2006 - 3:22am

I actually am, and could not get the exploit to work in our hosts, which should be vulnerable. I got one X server to hang. Also, you need root access to get access to /proc/[X servers pid]/maps to properly run the exploit (though those values are probably guessable). Setting 'Options "RenderAccel" "false"' seems to stop the hangs too.

Did anybody actually get the exploit to work?

*rolls eyes*

Omnifarious
on
October 17, 2006 - 10:52am

Where is the accountability and control? How did this bug go for two years and not get fixed? It is a problem, and it's exactly the kind of problem that Open Source deals with well and closed source deals with horribly.

I don't care if there are no examples in the wild. It shouldn't take an example of someone succumbing to the problem for the problem to be fixed. It should've been fixed 2 years ago when it was discovered, not now when it's embarassing them.

As soon as there's a graphics card with 80% the performance of an nVidia card and Open Source drivers, I'm buying it. I hate nVidia. They make a nice graphics card, but in all other respects their company is awful. They won't even open the source to the drivers for their motherboard hardware. What kind of idiocy is that? I won't use their motherboard hardware for that exact reason. The last thing I need is an exploit in my ethernet driver that doesn't get fixed for several years because nobody made a public stink about it.

Actually l'm pretty sure they

Anonymous (not verified)
on
December 5, 2006 - 6:24pm

Actually l'm pretty sure they already open sourced the nvidia nforce drivers.
http://www.nvidia.com/object/unix.html
This page says they are included in the standard linux kernel. The binary only part is just the graphics driver and they may not have an easy time opening that because they may have code from other sources in there that's protected.

I can't find anything in the

Anonymous (not verified)
on
October 16, 2006 - 1:33pm

I can't find anything in the release notes about a fix for this bug. How do you know it's fixed? If it has been, how does the average user get aware of the fact that an update is advisable? Or does the average user update to BETA versions in a timely fashion on principle?

Re: I can't find anything in the

Anonymous (not verified)
on
October 16, 2006 - 2:12pm

Someone, apparently an nvidia employee, claims the bug has been fixed in the beta drivers here:
http://www.nvnews.net/vbulletin/showpost.php?s=87867d1f473f5e912c412a23e...

It's a real shame they do not mention the bugfix in the release notes, let alone publically urge their users to upgrade.

"Re: X server crash on manipu

Anonymous (not verified)
on
October 16, 2006 - 2:19pm

"Re: X server crash on manipulation of certain strings"

Maybe it does fix also the vunerability, and not only the specific crash
reported there.
We wouldn't know, we don't have the sources.

bs, there is no such thing as

Anonymous (not verified)
on
October 17, 2006 - 12:02am

bs, there is no such thing as closed source. Learn to read assembly and quit jabbering about not having the source.

No such thing as closed sourc

Anonymous (not verified)
on
October 17, 2006 - 7:43am

No such thing as closed source ?
Why do you think the GPL specifically mentions that the preferred form of source code includes makefiles and that kind of thing ?
Yes, it's to avoid smartarse lawyers that'd say "you got the assembler, so you got the source".

It's because their drivers ar

Anonymous (not verified)
on
October 16, 2006 - 6:33pm

It's because their drivers are the buggier than early Vista betas. I can't count on both hands and feet how many different issues I've had with their Linux driver and what still hasn't been fixed. *Shrug*

"Foaming at the mouth"? You d

Anonymous (not verified)
on
October 16, 2006 - 2:04pm

"Foaming at the mouth"? You don't happen to work for NVIDIA, do you? Lonni?

Hi Lonni! Everyone meet Lonni

Anonymous (not verified)
on
October 16, 2006 - 2:05pm

Hi Lonni! Everyone meet Lonni (above). She works for Nvidia. She's kind of a PR troll.

Lonni, does Nvidia really believe that all their Linux users should run beta software?

Why does the changelist for the beta driver not mention that this bug was fixed?

If Nvidia cannot keep the holes out of their non-beta software, why would anyone want to risk running the beta drivers?

Why not just publish documentation for the chips? Is it because open source people would not be able to write better software for the chips than Nvidia themselves write?

Can you please answer these questions posed above?

> Is it because open source p

Anonymous (not verified)
on
October 16, 2006 - 2:22pm

> Is it because open source people would not be able to write better software for the chips than Nvidia themselves write?

You seriously don't believe that tripe!. Who fucking died and made Open Source programmers the ONLY people to write bug free software?. Did you forget about Firefox's security bugs already?

Really, some of the open source programmers are bloody morons who don't even have a computer science degree. Sorry but I'll trust Nvidia 1000 times over open source programmers.

You would trust Michael Jacks

Anonymous (not verified)
on
October 16, 2006 - 2:31pm

You would trust Michael Jackson to baby sit your children 1000 times over an open source programmer.

Let's compare apples to apple

Anonymous (not verified)
on
October 16, 2006 - 2:31pm

Let's compare apples to apples... Name one closed-source X.org driver that has anywhere NEAR the reliability record of any open source X.org driver. SiS parts are horrifyingly poor, yet thanks to Thomas Winschhoffer the drivers are solid. The Intel driver has feature parity with both Nvidia and ATI, it just doesn't suffer all the bugs.

All the closed source X.org drivers that I've used have been a pile of hard crashes and root exploits (mostly because the vendor hardly spends any engineering time on them). Suspend/resume? Works on every open source driver, notoriously buggy on every closed source driver. Giving an attacker root privs just by the user viewing a bad web page? I only know of one other X exploit of this magnitude, and that was fixed in a day. Nvidia has let this one languish since 2004 (sure, they didn't know it was rootable, but they should have at least done a little due dilligence here... they have the source!)

Your faith in Nvidia and ATI closed source development is quite misguided.

shouldn't that be "I find yo

Anonymous (not verified)
on
October 16, 2006 - 3:09pm

shouldn't that be
"I find your faith in closed source development ... disturbing"

Make your angle of view wider

Anonymous (not verified)
on
October 16, 2006 - 3:22pm

OMG. Stick your head out of your ass. Every open source driver is either broken half the time, or immensingly and breathtakingly slow another half.
Suspend/resume works ? Say it again, and I'll happily show you my i855GM (how long this platform is available? three years ? ) , which can resume from STR - sometimes at best, and freeze solidly most of the time. Speed ? To enable direct rendering, you need to install separate drm git tree clone (not official release, nightlies (who talks about beta ?)) . And to enable dual head with mergedfb and direct rendering and reliable (for weeks, day after day suspend/resume cycles) STR - no way. Open source is just not there.
Stop FUDing and misleading.
And about security - root-exploitable driver fault is a direct consequence (let's call it a feature) of so-lovely-time-proven-network-transparent-X-Windows and it's design, which is being defended by blind zealots from another space/time continuum. Move drivers to userspace. Do it microkernel way. Do it right, after all. And give stable ABI . (Or stable API, for three years, for someone's sake).

Userspace drivers

Anonymous (not verified)
on
October 17, 2006 - 2:50am

Erm... X drivers are primarily in userspace anyway. For 2D-only drivers, X drivers are ENTIRELY in userspace - they just need appropriate privelages (root on most systems) to access video memory and registers.

The 3D DRI drivers are split in two. The kernel component provides a mechanism for the userspace component to talk to the card, and usually implement security or validity checks on submitted commands. The user-space component is the part where all the real work is done, and it uses the kernel-mode interface only to talk to the card.

Do some research before you start spouting nonsense.

Hey look - someone here caugh

Anonymous (not verified)
on
October 21, 2006 - 7:20pm

Hey look - someone here caught five minutes of an operating systems class during a university open day.

p.s. you're an idiot.

Concerning Suspend/Resume, th

Anonymous (not verified)
on
October 17, 2006 - 2:38am

Concerning Suspend/Resume, those don't work with radeon opensource drivers. I'm using fglrx driver, and have no troubles with suspend/resume/hybernate.

Btw, I have WinXP (Lenovo ThinkPad R52 - got them with the laptop), and Windows crash when I do suspend. Ati drivers :) Hibernate, on the other hand works well.

That's funny, because I suspe

Anonymous (not verified)
on
October 17, 2006 - 8:07am

That's funny, because I suspend/resume my T42 with the xorg radeon driver at least twice a day. All OSes suck. All software sucks. Find some software that sucks least for what you're trying to do. In my world, a video driver that doesn't let me suspend sucks less than a video driver that gets me pwnd.

troll

Anonymous (not verified)
on
October 16, 2006 - 4:06pm

The nice thing about open source development is that when there are bugs found, they get FIXED, usually immediately. Firefox's security bugs generally have a 1-day or less turnaround time for a fix. Go do some research and compare that with Internet Explorer. If you need a reason why closed-source development generally sucks by comparison, that's why.

And while you're trying to pull the importance of computer science degrees into this, I can attest to the fact that they don't necessarily mean a goddamned thing. I earned my degree the way I was meant to earn it, but my graduating class included quite a handful of people who were only there because they were able to successfully ride through difficult classes on the coattails of people like myself. University degrees lately mean less about how much you know, and more about how good you are at working the system without actually knowing jack shit.

> Firefox's security bugs gen

Anonymous (not verified)
on
October 16, 2006 - 4:56pm

> Firefox's security bugs generally have a 1-day or less turnaround time for a fix.

This is simply not true. Just because the public gets informed with an update, this doesn't mean the bugs were not known before (to a smaller audience, but not exclusively to the Mozilla devs. And some of the flaws within Firefox where known months before they were fixed. mozilla.org hasn't a good track record in this regard.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.