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 potential risk. As it turns out the handling of environment variables is very badly written for cvg (the voodoo2) it contains brilliant code as: --- char buffer[1024], filename[256]; <snip> strcpy(filename, getenv("VOODOO2_FILE")); --- 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 -vsync on/off -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. Alan
Hmm, 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 version, good. 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) solve this?
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. Alan
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 (extra) risc. 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 wrapper scripts. 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.