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.
NVIDIA released the 1.0-9625
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
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
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
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
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
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
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
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
Do _not_ open this url, read it carefully and you'll see it's a nasty trick.
Can someone who is not runnin
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
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
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
It didn't crash mine. FF 2.0rc3, Xorg 7.1.1, "radeon" driver.
Works for me.
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
No, it doesn't crash with the open source radeon driver.
Ahem, I'm using the latest nv
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
*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
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
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
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
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.
Awesome - killed my machine for good
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
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
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
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
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
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*
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
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
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
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
"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
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
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
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
"Foaming at the mouth"? You don't happen to work for NVIDIA, do you? Lonni?
Hi Lonni! Everyone meet Lonni
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
> 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
You would trust Michael Jackson to baby sit your children 1000 times over an open source programmer.
Let's compare apples to apple
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
shouldn't that be
"I find your faith in closed source development ... disturbing"
Make your angle of view wider
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
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
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
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
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
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
> 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.
Correct
There was (is ?) a security bug that the firefox team hid from the world for a couple of years. When the bug became public they still didn't fix it.
You asked 3 very good questio
You asked 3 very good questions. It's a shame that you then invalidated that good work by asking the tired old troll question "Why not just publish documentation for the chips?" Yeah, right. Nvidia has been shirking this question for years. Why do you think that a good answer could magically appear now?
I wish Lonni would answer your other 3 questions though because "use the unsupported beta with the missing release notes" is such an obviously stupid thing to tell your users. Maybe Nvidia doesn't understand the meaning of the word "root exploit" and the trust implications therein...