Mariano Alvarez Fernandez wrote:
Anyway I think demogrx is only a demo, but is good to know about this problem.
Even though, I think they security implications should be pointed out very clearly, since not every user is probably aware of the problems. It should be stated that it's a big risk on anything but a single-user, non-networked, personal machine.
Also, it might be useful to use replace the `system' call by a simple `fork'/`exec' (Unix) or `spawn' (Dos/Windows) to alleviate at least the problems in the demo. Since (at least from the code fragment below) it seems to call a program with explicit path and no arguments, redirections or anything, calling a shell would be unnecessary anyway.
(The two suggestions are meant in addition to each other, since removing the `system' call will only get rid of some security problems, but probably not all that might exist in the demos.)
fabio wrote:
Hi, i've been interested in using grx libraries to make a media station (something like the FreeVo Project, http://freevo.sourceforge.net/). I've find a security issue in the demogrx test binary. If i want to use the svga driver, the readme say that i must setuid the test programs to make them work. In demogrx.c there is an invocation of system():
(line 402): for (i = 0; i < NDEMOS; i++) { if (ev->p1 == ptable[i].cid) { gfaz_fin(); #if defined(__MSDOS__) || defined(__WIN32__) if (ev->p1 == ID_MODETEST) strcpy(nprog, "..\bin\"); else strcpy(nprog, ".\"); #else if (ev->p1 == ID_MODETEST) strcpy(nprog, "../bin/"); else strcpy(nprog, "./"); #endif #if defined(__XWIN__) strcat(nprog, "x"); #endif strcat(nprog, ptable[i].prog); system(nprog); :(line 420)
Do not use system() from a program with suid or sgid privileges, because strange values for some environment variables might be used to subvert system integrity. [...]
In poor words, a user can (for example) make a ln -s /bin/sh rgbtest , then execute the demogrx program, click on "Rgbtest" and he will gain a root shell. I've tried it on Knoppix 3.1, Slackware 9.0, and it works.
This exploit assumes you have write permissions to the demo directory. In this case, all is lost anyway (even `exec' won't help). But that doesn't have to be the case. Usually the admin will install the demos in a directory which is not publicly writable, including `../bin'. (A normal user can compile the demos himself, but not make them setuid root.)
But with `system', there are probably many other ways to exploit the (real) shell, e.g. setting environment variables as the manpage quote says (perhaps `IFS' and such).
Frank