Thanks for the info.
Anyway I think demogrx is only a demo, but is good to know about this problem.
Thanks again, and feel free to post about your project to the grx mailing list.
M.Alvarez
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)
This is extracted from the system(3) man page:
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. Use the exec(3) family of functions instead, but not execlp(3) or execvp(3). system() will not, in fact, work prop- erly from programs with suid or sgid privileges on systems on which /bin/sh is bash version 2, since bash 2 drops privileges on startup. (Debian uses a modified bash which does not do this when invoked as sh.)
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. The solution is to use the exec(3) family of functions.
Good work for the library, i've find it very useful to write quickly graphical applications. I will notice you when my media station will be ready, if you like :-)
Fabio Bas
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