|
|
Subscribe / Log in / New account

Privilege escalation vulnerability in the NVidia binary driver

[Posted August 1, 2012 by corbet]

People running the proprietary NVidia graphics driver on systems with untrusted users may want to have a look at this exploit posted by Dave Airlie. "I was given this anonymously, it has been sent to nvidia over a month ago with no reply or advisory and the original author wishes to remain anonymous but would like to have the exploit published at this time."
to post comments

Privilege escalation vulnerability in the NVidia binary driver

Posted Aug 1, 2012 15:20 UTC (Wed) by flammon (guest, #807) [Link] (5 responses) 


/* Anonymous
 *
 * How to use: sudo rm -rf /
 *
...

That's one way to filter out the script kiddies lol.

Privilege escalation vulnerability in the NVidia binary driver

Posted Aug 1, 2012 17:40 UTC (Wed) by HelloWorld (guest, #56129) [Link] (3 responses)

> That's one way to filter out the script kiddies
A rather ineffective one though. Current versions of GNU rm will only print this:
> rm: it is dangerous to operate recursively on `/'
> rm: use --no-preserve-root to override this failsafe

Privilege escalation vulnerability in the NVidia binary driver

Posted Aug 1, 2012 20:53 UTC (Wed) by ken (subscriber, #625) [Link] (2 responses)

Really that is great.

having tried to compile a broadcom kernel that modified the makefile so it needed an ENV variable that I had not set and thus having a make clean resulting in a recursive clean of /. I do see the usefulness of having a extra check on /.

Privilege escalation vulnerability in the NVidia binary driver

Posted Aug 1, 2012 21:08 UTC (Wed) by HelloWorld (guest, #56129) [Link] (1 responses)

Don't compile as root.

Privilege escalation vulnerability in the NVidia binary driver

Posted Aug 2, 2012 18:22 UTC (Thu) by jengelh (guest, #33263) [Link]

And with Open Build Service, you also get free isolation, starting from chroots, up to xen and kvm isolated instances.

Privilege escalation vulnerability in the NVidia binary driver

Posted Aug 9, 2012 16:11 UTC (Thu) by philomath (guest, #84172) [Link]

Reminds me of:

>Q:

>I'm having problems with my Windows software. Will you help me?

>A:

>Yes. Go to a DOS prompt and type "format c:". Any problems you are experiencing will cease within a few minutes.

(esr in "How To Become A Hacker).

Privilege escalation vulnerability in the NVidia binary driver

Posted Aug 1, 2012 16:19 UTC (Wed) by bros (subscriber, #75198) [Link] (7 responses)

Is this related:
http://nvidia.custhelp.com/app/answers/detail/a_id/3109

Seems to be fixed, isn't it? :)

Privilege escalation vulnerability in the NVidia binary driver

Posted Aug 1, 2012 16:30 UTC (Wed) by corbet (editor, #1) [Link] (6 responses)

Nope, not fixed.

Privilege escalation vulnerability in the NVidia binary driver

Posted Aug 1, 2012 23:01 UTC (Wed) by THe_ZiPMaN (guest, #27460) [Link] (5 responses)

On Debian Unstable/Experimental, with kernel from siduction version 3.5-0.towo-siduction-amd64 and nvidia drivers from experimental version 304.30-1 it doesn't work...

$ ./a.out
[*] IDT offset at 0xffffffff8172a000
[*] Abusing nVidia...
[*] CVE-2012-YYYY
[*] 64-bits Kernel found at ofs 0
[*] Using IDT entry: 220 (0xffffffff8172adc0)
[*] Enhancing gate entry...
[*] Triggering payload...
Killed

On dmesg I can see...

[59253.807679] BUG: unable to handle kernel paging request at ffffffff81a00000
[59253.807690] IP: [<00000000004016a7>] 0x4016a6
[59253.807704] PGD 160d067 PUD 1611063 PMD 0
[59253.807711] Oops: 0000 [#1] PREEMPT SMP
[59253.807717] CPU 3
[59253.807720] Modules linked in:<4>[59253.807826] xt_NFQUEUE<4>[59253.807943] battery ac button processor ext4 crc16 jbd2 mbcache btrfs libcrc32c zlib_deflate dm_mod sg sd_mod crc_t10dif mmc_block crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 aes_generic cryptd ahci libahci firewire_ohci libata sdhci_pci firewire_core crc_itu_t scsi_mod e1000e sdhci mmc_core ehci_hcd usbcore usb_common [last unloaded: scsi_wait_scan]
[59253.807989]
[59253.807993] Pid: 15945, comm: a.out Tainted: P O 3.5-0.towo-siduction-amd64 #1 Dell Inc. Latitude E6510
[59253.808000] RIP: 0010:[<00000000004016a7>] [<00000000004016a7>] 0x4016a6
[59253.808011] RSP: 0000:ffff8801d1161d08 EFLAGS: 00010006
[59253.808015] RAX: ffffffff81a00000 RBX: 00000000000003e8 RCX: 00007f6f600b4767
[59253.808018] RDX: 00007f6f6038ce10 RSI: 00000000000003e8 RDI: 00000000000003e8
[59253.808021] RBP: ffff8801d1161fc8 R08: 2e2e2e64616f6c79 R09: 00007f6f6058d700
[59253.808024] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000400ca0
[59253.808027] R13: 00007fffc1be7cb0 R14: 0000000000000000 R15: 0000000000000000
[59253.808031] FS: 00007f6f6058d700(0000) GS:ffff88022fcc0000(0000) knlGS:0000000000000000
[59253.808035] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[59253.808038] CR2: ffffffff81a00000 CR3: 0000000123308000 CR4: 00000000000007e0
[59253.808042] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[59253.808045] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[59253.808049] Process a.out (pid: 15945, threadinfo ffff8801d1160000, task ffff880220cfcf10)
[59253.808051] Stack:
[59253.808054] 00000000000003e8 00000000000003e8 0000000220484025 00007f6f600b4780
[59253.808061] ffff880222733f00 ffffea00064c0ef0 0000000000000000 ffff88019303b5a0
[59253.808068] 0000000000000028 00000000000000aa 00007f6f600b4000 ffffea0008812100
[59253.808074] Call Trace:
[59253.808087] [<ffffffff810bb2c3>] ? handle_pte_fault+0x2b8/0x7bc
[59253.808095] [<ffffffff812043b7>] ? pty_write+0x48/0x53
[59253.808101] [<ffffffff810b87c8>] ? pte_offset_kernel+0xc/0x38
[59253.808109] [<ffffffff8102b04e>] ? do_page_fault+0x274/0x2f2
[59253.808116] [<ffffffff8110ef90>] ? fsnotify+0x257/0x2a9
[59253.808122] [<ffffffff81051027>] ? __wake_up+0x35/0x46
[59253.808130] [<ffffffff810e5531>] ? vfs_write+0xaf/0xf8
[59253.808138] [<ffffffff8132ec39>] ? system_call_fastpath+0x16/0x1b
[59253.808140] Code: Bad RIP value.
[59253.808145] RIP [<00000000004016a7>] 0x4016a6
[59253.808155] RSP <ffff8801d1161d08>
[59253.808158] CR2: ffffffff81a00000
[59253.808162] ---[ end trace a7ace442feb7e225 ]---

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

Privilege escalation vulnerability in the NVidia binary driver

Posted Aug 1, 2012 23:15 UTC (Wed) by corbet (editor, #1) [Link] (2 responses)

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".

Privilege escalation vulnerability in the NVidia binary driver

Posted Aug 2, 2012 7:51 UTC (Thu) by THe_ZiPMaN (guest, #27460) [Link] (1 responses)

Yes, that was what I meant :)

Privilege escalation vulnerability in the NVidia binary driver

Posted Aug 10, 2012 8:48 UTC (Fri) by aigarius (subscriber, #7329) [Link]

The particular exploit code is not working anymore, but because there is an actual oops this means that the actual bug is not fixed and competent hackers can write a new exploit on the same bug. Or at least try to.

Privilege escalation vulnerability in the NVidia binary driver

Posted Aug 2, 2012 6:37 UTC (Thu) by Ricky123321 (guest, #86057) [Link]

Got the exact same behavior here on Squeeze but with kernel 3.2.0 amd64 and nvidia 295.59, both from the backports.

:(

Privilege escalation vulnerability in the NVidia binary driver

Posted Aug 2, 2012 10:42 UTC (Thu) by PaXTeam (guest, #24616) [Link]

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).

Privilege escalation vulnerability in the NVidia binary driver

Posted Aug 2, 2012 11:10 UTC (Thu) by bush (guest, #86065) [Link]

Set NVreg_ModifyDeviceFiles to 0 can deny common user direct access /dev/nvidia0.
If it set, you can see "direct rendering: No" in glxinfo.
But it will make gdm cannot start at some distribution.

Centos 6.3 64bit with nvidia 295.59 will exit after print [*] Abusing nVidia... without other message.
I don't known why... (didn't set NVreg_ModifyDeviceFiles=0)


Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds