Date: Fri, 19 Feb 1999 18:10:00 +0000 From: Chris Evans To: BUGTRAQ@netspace.org Subject: Security hole: "zgv" Overview: "zgv" is an image viewer which runs under SVGAlib at the linux console (probably BSD too). It has to be installed suid-root to access graphics hardware. History: "zgv" has a long history of security problems. This includes relatively boring and trivial buffer overflows to the more recent leak of privileged file descriptors to child processes. This latter hole was interesting. It demonstrated that while an SVGAlib application drops root privileges after initializing, it is still vulnerable to buffer overflows because the program holds a vital resource; a writeable file descriptor to /dev/mem. This applies to all SVGAlib programs. The new hole I have found _also_ involves leak of privileges to child processes. This is an issue because a user may supply via the "-a" option that zgv is to launch a different program to view the picture (using zgv just as a graphical file manager). The precise privilege leaked to child processes is iopl(3). This is a processor privilege on intel. iopl(3) gives access to all i/o ports (ouch) and also usage of the cli(), sti() commands. Going from iopl(3) privs -> root is non-trivial but very possible. I recommend no SVGAlib programs are installed on "secure" systems. Too many programmers of SVGAlib stuff assume that SVGAlib will drop all privs. It may drop root, but still retains resources which if taken over can lead easily to root (/dev/mem fd, iopl(3)). Best to just "rpm -e zgv". I have closed this hole in some RPMs for RedHat5.2 by disabling the "-a" option.[*] If you like/use zgv feel free to use these. They are at ftp://ftp.lmh.ox.ac.uk/users/chris/security. Here are the md5sums 02735c8871bdb7ea6250fa69e7aa32f8 zgv-3.0-7.i386.rpm 9175ae3db3c2fff266f595fde412913f zgv-3.0-7.src.rpm This incident leaves me curious as to which other programs use this privilege? The X server certainly does. Can anyone tell me if the X server ever launches child processes? Cheers Chris [*] I couldn't close this hole by doing iopl(0) in the child because, in Linux-2.0.x you need root privs to lower your iopl! I got this fixed in 2.2.x.