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.
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*?
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!
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 nvidia_drv.so, which is only available in binary form. Comments/suggestions would be appreciated.
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?
Suggest adding a warning if we go the options route: # !!! SECURITY WARNING !!! # DO NOT MODIFY OR REMOVE THE DEVICE FILE RELATED OPTIONS UNLESS YOU KNOW WHAT YOU'RE DOING. # ONLY ADD TRUSTED USERS TO THE VIDEO GROUP, THESE USERS MAY BE ABLE TO CRASH, COMPROMISE, OR IRREPARABLY DAMAGE THE MACHINE. options nvidia NVreg... (irreparably damage the machine because presumably over clocking can do that)
nvclock insecure temporary file creation files as bug 184071
I would prefer that we patch the file and report upstream (if they're not already aware) rather than make it a configuration issue.
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.
Doug: is there any update on this?
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.
Fixed in 1.0.7185, 1.0.9639, and 100.14.11. All are masked in the tree pending testing.
Thx Doug, let us know when they are ready to be unmasked and stabled by arches.
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.
Thx Doug. Do you want me to call arches now? (Not sure about the timing of the pkgmove).
Sure. We need 1.0.7185, 1.0.9639, and 100.14.11. wolf you ok with this?
Absolutely. 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.
x86 and amd64 please test and mark stable.
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 games-puzzle/neverball-1.4.0). experienced oddities/bugs will be reported here ;-)
9639 works fine on nVidia Corporation NV25 [GeForce4 Ti 4200]
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).
I'm on x11-drivers alias...
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
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 http://www.nvnews.net/vbulletin/showthread.php?t=93015
1.0.9639, and 100.14.09 stable on x86, leaving x86 cc'ed until we can test 7185
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.
x86 stable, thanks Matthias and Mark for testing
nvidia-drivers-1.0.7185.ebuild, nvidia-drivers-1.0.9639.ebuild, nvidia-drivers-100.14.09.ebuild amd64 stable
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 :)
(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.
GLSA 200708-14, sorry for the delay. Thanks everybody
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 2.1.2.12 (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 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -finline-functions -fprefetch-loop-arrays -ftree-vectorize" CHOST="x86_64-pc-linux-gnu" 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" DISTDIR="/local/distfiles" FEATURES="buildpkg distlocks metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org ftp://distro.ibiblio.org/pub/linux/distributions/gentoo/" LANG="en_US" LINGUAS="en" MAKEOPTS="--jobs=2 --quiet" PKGDIR="/local/packages64" 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-*" PORTAGE_TMPDIR="/local/gentoo/tmp" PORTDIR="/local/gentoo/portage" PORTDIR_OVERLAY="/local/gentoo/overlays/se /local/gentoo/overlays/xeffects /local/gentoo/overlays/xeffects-experimental" SYNC="rsync://rsync.gentoo.org/gentoo-portage" 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" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
In /etc/modules.d/nvidia: options nvidia NVreg_DeviceFileMode=0660 NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=27 It's "0660", not "660".
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.
Nvidia's own README states: NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=44 (or group 27 for us) NVreg_DeviceFileMode=0660 And my permissions on /dev/nvidia* are: crw-rw---- 1 root video 0660 is much more understandable than 432.
