Lucene search

K

zgv.iopl.txt

🗓️ 17 Aug 1999 00:00:00Reported by Packet StormType 
packetstorm
 packetstorm
🔗 packetstormsecurity.com👁 17 Views

Critical security hole in "zgv" allows privilege leak to child processes, risking system integrity.

Show more
Code
`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.  
  
-----------------------------------------------------------------------------  
  
Date: Sat, 20 Feb 1999 23:00:05 +0000  
From: Alistair Cunningham <[email protected]>  
To: [email protected]  
Subject: Re: Security hole: "zgv"  
  
On Fri, Feb 19, 1999 at 06:10:00PM +0000, Chris Evans wrote:  
  
[ snip zgv security discussion ]  
  
>  
> 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.  
>  
  
I've just tested, and this applies to quake 2. This is particularly bad,  
as quake 2 supports user written .so files. Quake 2 drops root privileges  
before loading them, but now it would appear that they can get root back.  
  
  
Alistair Cunningham (who's just chmodded -s quake2)  
  
--  
--------------------------------------------------------------------------  
Alistair Cunningham Selwyn College, Cambridge Email: [email protected]  
  
`

Transform Your Security Services

Elevate your offerings with Vulners' advanced Vulnerability Intelligence. Contact us for a demo and discover the difference comprehensive, actionable intelligence can make in your security strategy.

Book a live demo