Bug 156621
Summary: | Possible local root compromise | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Hans de Goede <hdegoede> |
Component: | Glide3 | Assignee: | Alan Cox <alan> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3 | CC: | security-response-team |
Target Milestone: | --- | Keywords: | Security |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-05-09 18:28:40 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Hans de Goede
2005-05-02 16:14:13 UTC
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. |