LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - General (http://www.linuxquestions.org/questions/linux-general-1/)
-   -   Beware the Nvidia blob (http://www.linuxquestions.org/questions/linux-general-1/beware-the-nvidia-blob-4175419968/)

H_TeXMeX_H 08-02-2012 08:54 AM

Beware the Nvidia blob
 
NVIDIA Linux Driver Hack Gives You Root Access
http://www.phoronix.com/scan.php?pag...tem&px=MTE1MTk

Although I have used the nvidia blob driver in the past, I only used it because I needed some 3D capabilities. The recent nouveau drivers provide good 3D support for most cards, so I use that now. The stability of the nouveau drivers has greatly improved with more recent releases as has the usability of the drivers. I notice that they now have power levels for my netbook and the fan does NOT run at 100% anymore. Rarely there is some graphics corruption and crashing with some 3D apps, but it is rare.

I am never going back to the blob, because it is not stable, not secure, not FLOSS, and not much better than nouveau for what I use.

I am posting this in the Slackware forum because perhaps people here care more about security and stability than in other forums. I have also seen many threads here about how to get the nvidia drivers working. The mods can move it if they see fit.

brianL 08-02-2012 09:23 AM

The nouveau driver didn't work on this desktop with the integrated graphics (nVidia 6150se/nForce 430), so I had to use the proprietary driver. I fitted a GTS 450 a while ago, but haven't taken the risk(?) of trying it with the nouveau.
P.S.
I'm a bit dubious about compiling & running that exploit (downloads as a .bin, but is actually a .c source file):
Code:

bash-4.1$ cd temp
bash-4.1$ file 86747-001.bin
86747-001.bin: ASCII C program text, with CRLF line terminators


mlangdn 08-02-2012 09:31 AM

I still use the nvidia driver. Nouveau is not for me and what I want. Security problems with software are not limited to Nvidia, so we always have to be on guard.

willysr 08-02-2012 10:03 AM

the file is C-based file, so you have to compile it first

brianL 08-02-2012 10:10 AM

Yeah, I know. But is it safe to run after compiling? I've glanced through the file, but don't really know enough about C.
Edit
Oh, what-the-hell, I'll take a chance! :eek: :)

mlangdn 08-02-2012 10:13 AM

Be adventurous brianL! Then report back and let us know... :)

brianL 08-02-2012 10:19 AM

Whoooaaaaaaaaaa!!! This is what happened:

Code:

brian@slackdesk:~/temp$ gcc exploit.c -o exploit
brian@slackdesk:~/temp$ ./exploit[*] IDT offset at 0xffffffff81955000[*] Abusing nVidia...[*] CVE-2012-YYYY[*] 64-bits Kernel found at ofs 0[*] Using IDT entry: 220 (0xffffffff81955dc0)[*] Enhancing gate entry...[*] Triggering payload...
Killed
brian@slackdesk:~/temp$
Message from syslogd@slackdesk at Thu Aug  2 15:13:56 2012 ...
slackdesk kernel: [18888.254013] Oops: 0000 [#1] SMP

Message from syslogd@slackdesk at Thu Aug  2 15:13:56 2012 ...
slackdesk kernel: [18888.254013] last sysfs file: /sys/devices/pci0000:00/0000:00:09.0/0000:02:00.0/resource

Message from syslogd@slackdesk at Thu Aug  2 15:13:56 2012 ...
slackdesk kernel: [18888.254013] Call Trace:

Message from syslogd@slackdesk at Thu Aug  2 15:13:56 2012 ...
slackdesk kernel: [18888.254013] Stack:

Message from syslogd@slackdesk at Thu Aug  2 15:13:56 2012 ...
slackdesk kernel: [18888.254013] Code:  Bad RIP value.                                                                                                                                                                                     
                                                                                                                                                                                                                                           
Message from syslogd@slackdesk at Thu Aug  2 15:13:56 2012 ...                                                                                                                                                                             
slackdesk kernel: [18888.254013] CR2: ffffffff81c00000


mlangdn 08-02-2012 10:39 AM

This is what I got:

Code:

exploit.c:607:20: warning: always_inline function might not be inlinable [-Wattributes]
exploit.c:438:29: warning: always_inline function might not be inlinable [-Wattributes]
exploit.c:397:28: warning: always_inline function might not be inlinable [-Wattributes]
exploit.c:375:19: warning: always_inline function might not be inlinable [-Wattributes]
exploit.c:345:20: warning: always_inline function might not be inlinable [-Wattributes]


273 08-02-2012 10:44 AM

I got that when I compiled it, when I ran it I saw "killed" after the point it said the exploit was being run, then messages similar to BrianL. The people on Slashdot who ran it seemed to see similar, I think only one of them had success.
Now I feel like I should wipe my system and reinstall though since I can't follow the ASM in the source file.

brianL 08-02-2012 10:47 AM

If the exploit succeeds, it should say:
Code:

printf("[*] Have root, will travel..\n");
Seems we're OK, from this (THe_ZiPMaN's post):
http://lwn.net/Articles/509131/

273 08-02-2012 10:56 AM

Hmm, after reading that link I think we're not safe. If the code's running in kernel space, but crashing, that means kernel space can be accessed through the exploit from userspace. Or am I misreading the comments on the linked page?

mlangdn 08-02-2012 11:03 AM

I should have also said that I am running a custom kernel. Maybe that's why it won't do anything.

brianL 08-02-2012 11:05 AM

Mmm, rereading these two quotes, it sounds as if we're OK as far as this exploit goes:
Quote:

It seems to me that it's fixed at least with my combination of kernel/drivers.
Quote:

That is an oops listing. That doesn't say "fixed" to me at all; it says "the exploit doesn't quite work with this particular version of the kernel and the driver".
I dunno, I'm a long way from being an expert.

273 08-02-2012 11:09 AM

I'm going by this:
Quote:

Originally Posted by PaXTeam
note the faulting insn: RIP: 0010:[<00000000004016a7>]

it's code in the *kernel's* code segment with a *userland* address (PaX/KERNEXEC and CR4.SMEP stop exactly this kind of exploit method, but this looks like a powerful bug, it could be exploited other ways). that is, the kernel is executing userland provided code, that's already proof for privilege escalation and the oops is due to the exploit's kernel payload not being bullet proof (something that's not hard to fix up, if that's your game).

Suggesting the hole is there but the exploit code isn't written to handle other kernels, but it could be.

brianL 08-02-2012 11:16 AM

Mmmm.
Should we:
PANIC!!!
or:
DON'T PANIC!!!
:scratch:


All times are GMT -5. The time now is 09:39 AM.