Red Hat Bugzilla – Bug 156621
Possible local root compromise
Last modified: 2007-11-30 17:11:05 EST
Glide3 is used by X when the user has a 3dfx card. It needs root rights so I
assume that it is called with root priviliges by X.
Glide3 can be tweaked in many ways by setting a shitload of environment
variables. The handling of the data which is given by the user through these
variables is anything but safe. On a kernel without non-excutable stack
protection this will be easy to exploit through simpel classic buffer overuns.
I've volunteered to take over Glide3 for Fedora Extras for FC4 since it wil be
dropped from FC4 core. Because of this I was hoping todo a quick audit for any
possible security problems, as I realised that the env-variables might be a
As it turns out the handling of environment variables is very badly written for
cvg (the voodoo2) it contains brilliant code as:
char buffer, filename;
and not a problem but gives an idea of the quality of the code:
buffer[strlen(buffer)-1] = 0;
Because of the quality it is quite hard to read the code, but one thing is for
sure, it is FULL of potential bufferoverruns, also in the h3 and h5 parts which
are shipped with FC1-3, RH ?-9, RHEL ?-4 .
Another problem is that the environment variables allow users to:
-force a different (including bigger) ramsize then the card has
-force certain registers to a different initial value then the default init-
sequence writes, without any checks
-specify an alternate voodoo.ini, whose parser is shit and most likely can again
be used to generate bufferoverflows and this file allows all kinda nasty
settings like those above.
So it is a mess :| . My first plan was to fix the code. But:
-the possibility to tweak the way Glide interacts with the hardware is scary
-the code is really awfull, fixable but really really awfull
Currently I'm thinking about just ripping out all the tweak through environment
options except for a few really usefull and save ones like:
-disable the annoying 3dfx splashscreen
-possible others I find as I sift through the source
We've never shipped glide as root because it doesn't need to be priviledged in
its DRI mode. In theory the kernel DRI code is providing the protection needed
in DRI modes.
OIW the glide library is loaded as part of libGL by X-clients and not as part
of the X-server process, right?
And the amount of possible register tweaking also seems limited in the DRI
I'll do some more investigating into this tomorrow. For FE I also plan on
shipping support for the VooDoo2 which really has all the mentioned problems
except that it is not loaded by X, but loaded by libGL (mesa) by apps, which
then need to be run as root, which could create problems again. How do we (I)
I don't think the raw root run one can be made safe. Probably voodoo2 needs DRI
support (which is doable if a little demented). Voodoo1 is probably not feasible
for DRI though.
Hmm, I was planning on reviewing Glide3 h3/h5 for dangerous env variables, but I
just realised that if glide3 can be made to hit the hardware in a dangerous way
through DRI, that a normal user always can hit the hardware in a dangerous way
through DRI. Since he can install its own binaries which do this.
So since glide3 h3/h5 is run as user and not as root, all the tweak
possibilities and the bufferoveruns are not a bigger security risc then DRI.
The glide lib in my new package for cvg (voodoo 2) currently isn't used on
anything, but the plan is to build a mesa for it with a generic wrapper script
which sets LD_LIBRARY_PATH so that the voodoo2 specific mesa gets loaded. Now
this will require root rights.
If we don't provide any means to become root and test for root in the wrapper
script and otherwise bail, the user must first be able to become root and if he
is already able to become root all the holes in Glide for cvg also are not an
So I believe this bug can be closes, agreed?
And should it then become public?
I'm planning on fixing up all the bufferoveruns later anyways since they are
just plain wrong but if this doesn't have any security implications, that can
wait a while.
Agreed. Note btw that you can't mix X using Voodoo2 with cvg + mesa, also we
don't ship the kernel driver for full screen voodoo2 mesa, not that this helps
much since you can seriously upset a Voodoo card given direct access. It would
reduce the problem to DoS attacks however and provide a basis for a DRI driver
in the process.
My plan is to build the Mesa from www.mesa3d.org with Glide support and then
provide a script which will set LD_LIBRARY_PATH and MESA_GLX_FX=f . This script
won't be part of /etc/profile.d but must be used like strace and the arts / esd
This will enable the user to run thinks like ppracer and others. As long as the
applications output is opengl only (not opengl mixed with X-2d) this will work.
Also the user should NOT alt-tab away or hit any other window hotkeys which
causes the app to loose focus.
I know that the kernel doesn't ship with /dev/3dfx support, but thats fine I'll
just let the script check that it is run as root, that way we don't have to
worry about security concerns.
A DRI solution would also be cool, you (Alan) once wrote that this should be
doable and could be used in combination with a 2d driver for the voodoo2 to use
the voodoo2 as a complete graphics card and allow in window rendering. Is this
doable for somebody with almost zero X-driver and DRI experience, but with good
C-skill and some (mostly 2d) graphics skills? If so in what timeframe?
The code itself is not too demanding. A DRM driver is effectively a lock
arbitrator and access control. In the case of the Voodoo1/2 that might need a
command validator if using the pipeline command mode so that things like "change
mode" can be screened out. The rest is texture management/screen blits and the
like in user space which Glide would do most of already.
Its not easy as the documentation is not brilliant and you have to write pieces
of so many different things. A fixed /dev/3dfx looks quite doable with the new
pci layer however.