Bugzilla Bug 183567

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.