Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 183567 - x11-drivers/nvidia-drivers: insecure permissions on /dev/nvidia* (CVE-2007-3532)
Summary: x11-drivers/nvidia-drivers: insecure permissions on /dev/nvidia* (CVE-2007-3532)
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
Whiteboard: A3 [glsa]
Depends on:
Reported: 2007-06-28 19:15 UTC by greg
Modified: 2011-10-30 22:38 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description greg 2007-06-28 19:15:35 UTC
A complete lack of security checking allows any user to change video card settings such as clock speed, memory speed, and fanspeed to values that can crash the system and damage the video card. 

Reproducible: Always

Steps to Reproduce:
1.Do nvclock -m (enter a value unreasonable for your card)
2.Watch X lock up and/or your video card break

Actual Results:  
The system crashed.

Expected Results:  
nvclock should not have allowed an unprivileged user to change settings.
Comment 1 Tavis Ormandy (RETIRED) gentoo-dev 2007-06-28 19:29:53 UTC
It looks like the problem is /dev/nvidia* get 666 by default, these should be 660 root:video if it does need to be written to, so that only trusted users can interfere with it.

nvclock also creates /tmp/nvclock insecurely *sigh*.

x11-drivers guys, is it possible to change the permissions on /dev/nvidia*?
Comment 2 Tavis Ormandy (RETIRED) gentoo-dev 2007-07-02 17:45:58 UTC
dberkholz, our resident X guru, confirms that there is no reason to maintain those permissions. At the /very least/ they need to be 660 root:video.

We need to fix this pretty quickly, I dont know what other crazy stuff you get out of /dev/nvidia, but at the very least you can kill the system or probably leak sensitive information.

Adding cardoe, who looks like nvidia/udev maintainer.

Cardoe, please help!
Comment 3 Doug Goldstein (RETIRED) gentoo-dev 2007-07-02 18:21:44 UTC
I'm at a bit of a loss how to fix this. nvidia stopped using the sysfs interfaces because the kernel guys said those APIs are GPLed so release your sources. So they internally make those device nodes.

The node is made by loading, which is only available in binary form. Comments/suggestions would be appreciated.
Comment 4 Tavis Ormandy (RETIRED) gentoo-dev 2007-07-02 21:44:41 UTC
Okay, I looked into this issue, it looks like the solution is to pass options to the nvidia kernel module.

options nvidia NVreg_DeviceFileMode=432 NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=27 NVreg_ModifyDeviceFiles=1

(where 432 is 0660 in decimal, and 27 is the gid of video group, which i guess we'll have to lookup in the ebuild)

We could either:

generate this line and make it compulsory when nvidia-drivers is installed, or modify the file os-registry.c when compiling.

Annoying side effect is people are going to have to add themselves to the video group, but I think is necessary, and we can publicize this in a glsa.

What do you think is the best course of action Doug?
Comment 5 Tavis Ormandy (RETIRED) gentoo-dev 2007-07-03 11:06:48 UTC
Suggest adding a warning if we go the options route:

options nvidia NVreg...

(irreparably damage the machine because presumably over clocking can do that)
Comment 6 Tavis Ormandy (RETIRED) gentoo-dev 2007-07-03 11:10:27 UTC
nvclock insecure temporary file creation files as bug 184071
Comment 7 Chris Gianelloni (RETIRED) gentoo-dev 2007-07-05 17:38:56 UTC
I would prefer that we patch the file and report upstream (if they're not already aware) rather than make it a configuration issue.
Comment 8 Doug Goldstein (RETIRED) gentoo-dev 2007-07-05 18:25:49 UTC
it's probably safe to assume it's been reported upstream since it has a CVE entry associated with it.

I've been working on replacement ebuilds for all the current ebuilds in the tree and also to bring out a decently working 100 series driver. However it appears trapni has been committing user submitted ebuilds for the 100 series straight into the tree.

It also is not possible to patch the file since we would have to perform a group lookup of the group "video" and patch the file in the ebuild based on the results of the lookup. This is a terrible hack.

The proper way would be for the nVidia drivers to export fully via sysfs to work with udev and allow udev to handle this. However, a bunch of kernel hackers have decided their APIs are GPLed to try to force nVidia to release their sources, instead they just stopped using the kernel APIs. Which sticks us in the place of using their terrible devnode creation code.

As such, I have an ebuild ready to go for the 100 series and am readying ebuilds for previous versions as well.
Comment 9 Tavis Ormandy (RETIRED) gentoo-dev 2007-07-11 09:42:44 UTC
Doug: is there any update on this?
Comment 10 Doug Goldstein (RETIRED) gentoo-dev 2007-07-11 13:47:42 UTC
100.14.11 is in the tree. It causes one of my machines to hard lock after 5 minutes. There are other user reported issues.

I'm still waiting on verification if older Nvidia releases can be fixed by this since I only have a GeForce 8x00 series card available to me currently and that requires 100.x.y series drivers.
Comment 11 Doug Goldstein (RETIRED) gentoo-dev 2007-07-14 11:25:49 UTC
Fixed in 1.0.7185, 1.0.9639, and 100.14.11. All are masked in the tree pending testing.
Comment 12 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2007-07-15 07:50:33 UTC
Thx Doug, let us know when they are ready to be unmasked and stabled by arches.
Comment 13 Doug Goldstein (RETIRED) gentoo-dev 2007-07-16 17:12:21 UTC
unmasked the ebuilds this morning. I've had 3 testers of the 9639 series get back to me and 5 for the 100.14.11 series. No one has gotten back to me about 7185.

Once 7185 is marked stable, I need to add a pkgmove from nvidia-legacy-drivers -> nvidia-drivers and delete nvidia-legacy-drivers.
Comment 14 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2007-07-16 19:29:22 UTC
Thx Doug. Do you want me to call arches now? (Not sure about the timing of the pkgmove).
Comment 15 Doug Goldstein (RETIRED) gentoo-dev 2007-07-16 19:32:40 UTC
Sure. We need 1.0.7185, 1.0.9639, and 100.14.11. wolf you ok with this?
Comment 16 Chris Gianelloni (RETIRED) gentoo-dev 2007-07-17 19:48:50 UTC

7185 requires a GeForce 4 or lower (not 100% true, check the README/Appendix A for a complete list)

9639 should run on anything from a 5200 though a 7950.

100.14.11 should run on anything newer than a 6200.

Of course, there are other cards in any direction that these can run on, but the ones I listed are safe bets.
Comment 17 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2007-07-17 20:07:42 UTC
x86 and amd64 please test and mark stable.
Comment 18 Matthias Langer 2007-07-18 03:07:35 UTC
on x86:

nvidia-drivers-100.14.11  USE="gtk (-multilib)"

seem to be fine here in connection with

nVidia Corporation NV40 [GeForce 6800]

after a first glance (that means an uptime of ~30min; glxgears works as well as 

experienced oddities/bugs will be reported here ;-)
Comment 19 Raúl Porcel (RETIRED) gentoo-dev 2007-07-18 17:40:48 UTC
9639 works fine on nVidia Corporation NV25 [GeForce4 Ti 4200]
Comment 20 Chris Gianelloni (RETIRED) gentoo-dev 2007-07-18 19:32:51 UTC
Raúl, can you test 7185, too?  It works on your hardware and should work just fine, so long as you don't use COMPOSITE (specifically compiz/beryl, as Xgl works still even with the 7xxx series drivers).
Comment 21 Doug Goldstein (RETIRED) gentoo-dev 2007-07-18 20:51:36 UTC
I'm on x11-drivers alias...
Comment 22 Doug Goldstein (RETIRED) gentoo-dev 2007-07-19 14:35:06 UTC
I'd feel more comfortable with 100.14.09 being marked stable rather then 100.14.11 because of the numerous lockups reported with .11
Comment 23 Till Matthiesen 2007-07-19 18:02:35 UTC
100.14.09 might give a lot of bug reports either.
Due to a regression it's not possible to switch VTs 
for some vesafb console users.
This is said to be fixed/improved in 100.14.11
Comment 24 Raúl Porcel (RETIRED) gentoo-dev 2007-07-19 19:32:41 UTC
1.0.9639, and 100.14.09 stable on x86, leaving x86 cc'ed until we can test 7185
Comment 25 Gordon Malm (RETIRED) gentoo-dev 2007-07-19 22:16:45 UTC
Not a tester/dev but thought I'd contribute.  I have been using the 100.14.11 ebuild for almost 24 hours now with a 6800GS.  No regressions or problems vs. 9631-r1 observed, but user did need to be added to the video group as discussed.  Performance benchmarked the same as previous releases as well.
Comment 26 Raúl Porcel (RETIRED) gentoo-dev 2007-07-20 16:06:46 UTC
x86 stable, thanks Matthias and Mark for testing
Comment 27 Steve Dibb (RETIRED) gentoo-dev 2007-07-28 04:00:00 UTC
nvidia-drivers-1.0.7185.ebuild, nvidia-drivers-1.0.9639.ebuild, nvidia-drivers-100.14.09.ebuild amd64 stable
Comment 28 Pierre-Yves Rofes (RETIRED) gentoo-dev 2007-07-31 12:04:58 UTC
greg, did you discover this issue? If so, may I ask you your full name so I can credit you properly in the glsa? of course I can also skip the credit if you prefer to remain anonymous :)
Comment 29 greg 2007-07-31 20:28:33 UTC
(In reply to comment #28)
> greg, did you discover this issue? If so, may I ask you your full name so I can
> credit you properly in the glsa? of course I can also skip the credit if you
> prefer to remain anonymous :)

Yeah, I found it when I was messing with my fan speed settings. My full name is Gregory Shikhman.
Comment 30 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-08-19 23:00:35 UTC
GLSA 200708-14, sorry for the delay. Thanks everybody
Comment 31 christian 2007-08-29 02:27:07 UTC
i've upgraded nvidia-drivers from 1.0.9755-r1 to 100.14.09 but my devnode is still 666 root:root.  i logged out to console and reloaded the module but no joy.  i tried a cold boot but no joy.  hmm, modules.d/nvidia does have the option line for setting 660 root:video but does not seem to work.  this is not an overlay i'm using.  glsa-check reports the security flaw fixed, but this must be because i have the version it's looking for installed; it's not actually checking the permissions/owners.

Portage (default-linux/amd64/2007.0/desktop, gcc-4.1.2, glibc-2.5-r3, 2.6.20-gentoo-r8-20070816-64 x86_64)
System uname: 2.6.20-gentoo-r8-20070816-64 x86_64 AMD Athlon(tm) 64 Processor 3200+
Gentoo Base System release 1.12.9
Timestamp of tree: Mon, 27 Aug 2007 23:00:01 +0000
distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
ccache version 2.4 [disabled]
app-shells/bash:     3.2_p17
dev-java/java-config: 1.3.7, 2.0.33-r1
dev-lang/python:     2.4.4-r4
dev-python/pycrypto: 2.0.1-r6
dev-util/ccache:     2.4-r7
sys-apps/baselayout: 1.12.9-r2
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.61
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.17
sys-devel/gcc-config: 1.3.16
sys-devel/libtool:   1.5.24
virtual/os-headers:  2.6.17-r2
CFLAGS="-O2 -finline-functions -fprefetch-loop-arrays -ftree-vectorize"
CONFIG_PROTECT="/etc /etc/X11 /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/lib/fax /usr/share/X11/xkb /usr/share/config /var/spool/fax/etc"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c"
CXXFLAGS="-O2 -finline-functions -fprefetch-loop-arrays -ftree-vectorize"
FEATURES="buildpkg distlocks metadata-transfer parallel-fetch sandbox sfperms strict"
MAKEOPTS="--jobs=2 --quiet"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*"
PORTDIR_OVERLAY="/local/gentoo/overlays/se /local/gentoo/overlays/xeffects /local/gentoo/overlays/xeffects-experimental"
USE="3dnow 3dnowext 7zip X Xaw3d a52 aac aalib acl acpi aiglx alsa amd64 amr amuled apache2 apm arj arts asf audiofile avahi avi berkdb bidi bindist binfilter bitmap-fonts bl browserplugin bzip2 cairo cdda cddb cdio cdparanoia cdr cli cpudetection cracklib crypt css cups curl custom-cflags dbus device-mapper dga dio directfb divx divx4linux dlloader dmi dmx dri dts dv dvb dvd dvdr dvdread dxr3 eds emboss emerald encode erandom esd evo exif expat fam fame fat fbcon ffmpeg fftw firefox flac font-server foomaticdb fortran freetype ftp fuse gdbm ggi gif gimpprint glibc-omitfp glitz glut gmedia gmp gnome gnutls gpm grammar gstreamer gtk gtk2 gtkhtml gtkspell hal hfs httpd i8x0 iconv icq idn ieee1394 imagemagick imlib ipv6 irc isdnlog ithreads jack jack-tmpfs java jbig jfs joystick jpeg jpeg2000 justify kde kdeenablefinal kdexdeltas kerberos kqemu ladcca lame lcd lcms ldap lha libcaca libclamav libg++ libgda libvisual libwww linuxthreads-tls live lzo mad math matroska mbox mgetty midi mikmod mime mjpeg mmap mmx mng modplug motif mozbranding mozilla mp3 mp4 mpeg mplayer mudflap musepack mysql mythtv nas ncurses nls nntp nocd nptl nptlonly nsplugin ntfs nvidia objc ofx ogg oggvorbis openal opengl openmp oss ots pam pcre pdf pdflib perl perlsuid php pic pie png portaudio posix pppd profile pulseaudio python qt qt3 qt3support qt4 quicktime rar readline realmedia recode reflection reiser4 reiserfs rtc samba sdl session shared shorten slang smp sndfile socks5 sox speex spell spl sqlite sse sse2 ssl stream subtitles svg tcl tcpd test tga theora thesaurus threads threadsafe tiff tk toolbar tools transmitter truetype truetype-fonts type1-fonts udev unicode usb userlocales v4l vcd vdr vlm vorbis wmf wmp wxwindows x264 xanim xcomposite xfs xine xinerama xinetd xml xml2 xorg xpm xprint xv xvid xvmc yahoo zip zlib" ALSA_CARDS="ens1370 intel8x0 mpu401" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" LIRC_DEVICES="hauppauge" USERLAND="GNU" VIDEO_CARDS="nv nvidia vesa"
Comment 32 Paul Bredbury 2007-08-29 04:33:40 UTC
In /etc/modules.d/nvidia:

options nvidia NVreg_DeviceFileMode=0660 NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=27

It's "0660", not "660".
Comment 33 Doug Goldstein (RETIRED) gentoo-dev 2007-08-29 13:03:57 UTC
The /etc/modules.d/nvidia DeviceFileNode is not in regular 0660, it's got to be 432 to achieve the desired effect. Most likely you failed to run etc-update and update properly after installing the new version.
Comment 34 Paul Bredbury 2007-08-29 17:01:47 UTC
Nvidia's own README states:

NVreg_DeviceFileGID=44 (or group 27 for us)

And my permissions on /dev/nvidia* are:

crw-rw---- 1 root video

0660 is much more understandable than 432.