Date: Fri, 19 Feb 1999 18:10:00 +0000
From: Chris Evans <[email protected]>
To: [email protected]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.
